At 8:09 PM -0600 5/2/10, Ashley M. Kirchner wrote:
Slightly OT, but I can't think of a better forum to ask this in.  I'm sure a
lot of us here have at some point or another built a system that requires
registration to gain access.  What I'm trying to figure is how to set
different levels of access.

We're building a large site for a school district, to be used by both
students and parents.  When a student logs in, they gain some access to the
site, and when a parent logs in, they gain access to other sections on the
site.  That's all fine and dandy, it's the actual registration process that
I'm having a hard time with.

How to determine if a registration is a student or a parent.  Do I simply
give them a check box (or other method) to pick from (student or parent) and
hope they're being honest?  Has anyone here have to deal with that in the
past, and would you be willing to give me some ideas of what you did?


Excellent question.

My advice is to start at the top and work down. Set up an overall top-administrator who determines who is going to be the next level down and so forth. You may have as many levels as you need.

The operation is simply one of controlling who has access to what.

The top-admin [Level A] should have access to ALL authorizations and can change ALL authorizations.

The next level down [Level B] should have access to determine authorizations for Level C access and the top-admin can override such determinations.

The next level down [Level C] has access to determine authorizations for level D, but Levels A and B can override. The levels cascade down as demonstrated above.

The requirement for the various levels is dependant upon what *you* [Level A] determines beforehand.

The *requirements* for any *Level* might be an email address that works (double-opt-in); and/or a teacher ID ; and/or a student ID, and/or a legitimate mailing address; and/or whatever you can verify. The point is to verify all those who have access to any Level in the "protected" scheme. You absolutely do not want to allow anyone access to post anything on your site without first identifying themselves.

While all of this can become very confusing, it should be pointed out that this is simply restricting access to certain scripts by personnel authorized by those up the chain of command.

The way this can be done is to place an authorization script (i.e., require() ) on those scripts you want access restricted. The authorization script simply checks the database to see if the user/password match for the level of security required before allowing the user to continue with *this* script.

The way I do this is in the required auth.php script I use SESSIONs for each level. If the user has provided authorization for Level A anywhere in their current event, then they have access to everything. If the user passes only level C, then the user has access to only those things designated as Level C access.

At the start of every script I place the require(auth.php) AND I set a level for *this* script, such as this script is a Level C script (i.e., $level ="C";). That way all users who have a Level A, B, or C clearance can run/access the script. Likewise for higher security scripts, such as Level A -- this script has a $level = "A" requirement and thus Level B and C users can't run the script.

Now, some of this organization layout will come out in the wash as you write scripts. Clearly you don't want the general public to have access to Level A scripts and thus you should keep those URL's from them. BUT, you don't need to*hide* the URL's (just in case someone finds out) because even if someone finds the URL, they need clearance to access them. You only need to provide the URL's necessary for whatever clearances the users of the scheme have.

I hope this gives you a better idea of how to handle this type of problem.




PHP General Mailing List (
To unsubscribe, visit:

Reply via email to