I guess I need to chime in. Besides the fact that his is a moron - the customer is always right.... - at least as long as he is paying.... OK simplest way to handle this is: 1) Set the_db ownership and permissions to chown theboss:employees the_db chmod 0700 the_db 2) Attach a script to his login script that does chmod 0770 the_db 2) Attach a script to his logout script that does chmod 0700 the_db Remind him that he must logout normally to lock the DB On Sep 12, 2010, at 12:37 PM, Joshua Kehn wrote: > Tedd- > > Would he consider access to another database? I.e. a separate, say memcached db which stores the "boss" status? > > An issue with the temporary file would also be session length, if the session expires without the user explicitly logging off, the file wouldn't be removed. A way to bypass this would be to add some sort of session expiration header to the file and update that. > > And couldn't you make a simple check if the boss is logged in or not by the ability to access the database? > > Regards, > > -Josh > ____________________________________ > Joshua Kehn | Josh.Kehn@xxxxxxxxx > http://joshuakehn.com > > On Sep 12, 2010, at 12:32 PM, tedd wrote: > >> Hi gang: >> >> I have a client who wants his employees' access to their online business database restricted to only times when he is logged on. (Don't ask why) >> >> In other words, when the boss is not logged on, then his employees cannot access the business database in any fashion whatsoever including checking to see if the boss is logged on, or not. No access whatsoever! >> >> Normally, I would just set up a field in the database and have that set to "yes" or "no" as to if the employees could access the database, or not. But in this case, the boss does not want even that type of access to the database permitted. Repeat -- No access whatsoever! >> >> I was thinking of the boss' script writing to a file that accomplished the "yes" or "no" thing, but if the boss did not log off properly then the file would remain in the "yes" state allowing employees undesired access. That would not be acceptable. >> >> So, what methods would you suggest? >> >> Cheers, >> >> tedd >> >> -- >> ------- >> http://sperling.com/ >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
