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.k...@gmail.com > 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
