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?
Thanks!
Ashley:
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.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
