Very simply I protect whole pages on my member's website by include()'ing a script called auth.php into the top of each page. Rather than using a binary string to turn functions 'on' and 'off', I do things a bit more general than that. I have defined levels of access (ie, L1, L2, L3, etc..) stored in the member's table in the database. At the top of each page I wish to protect I write ($min_access = 'L2') to define a minimum level of access. If the user has L2 access or greater they'll fall right through the auth.php and end up on the page. Otherwise one of the conditionals will catch them like a net and dump them into the logout() function which kills the session and displays the login screen with a lovely "ACCESS DENIED" (or other appropriate text) message. In this way I can protect any number and type of webpage (so long as I rename it .php) without registering the filename. And all of my staff and admin scripts can remain public instead of behind some .htaccess file.
As for the complexity of auth.php. It's hardly complex but I'm fairly thurough in my check. The auth.php script is actually about 150 lines of code and does timeout, tracks the member's movement and more... but it could be as simple as a single db query. This is the best continuous pervasive authentication scheme I have devised. It's probably not as good as other systems out there but it does the job in the limited scope of protecting my member's site. :) -Keivn ----- Original Message ----- From: "Jason Markantes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 04, 2002 10:43 PM Subject: [PHP-DB] permissions "system" > Howdy All- > > I've poked around the net for some snippets, and have done my own in the past, > but wanted to get some more ideas on how you do a permissions "system". This > means, in your application, how do you control and enforce different > permissions for different users? > > Simple example: An image repository. You have users who can download images > and/or upload images. And certain users can only search for images within a > certain criteria. > > What I've done in the past is created a permission_flag column for each user. > Zero or One determines whether or not the user can do that function, and the > various functions are indicated by position (or index). So if you had upload > and download functions, you can have: > > 01 = can download, but can't upload > 11 = can download and upload. > > If I add a new function, I have to add another digit (and potentially increase > the column size if things grow faster than planned). > > To enforce this, as a user attempts each function, I simply check the function > "index" and see if it's one or zero. > > With me so far? > > Now, for restricting database access: > > What I've done is created a user_where column for each user. In this column I > add a where clause that's appended to each and every search the user attempts > (with the usual input safety checks for common db exploits). > > For example, if a user can only see Approved images (in my pretend application > example here), the user_where value might be "category = 'Approved'". For > multiple values, it could be "category IN ('Approved', 'Pending')". > > Does this make sense? How are other people doing things? I've given a little > bit of thought to it, but not enough. With all the applications out there > everyone at some point has to come up with their own system. > > Ideas? > > Thanks, > Jason > > > > ===== > Just Another Fu@#in' Adventure > http://markantes.com/jason > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php