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
