--- Justin French <[EMAIL PROTECTED]> wrote: > I just need a quick sanity check.
I'm no doctor, but I think you're sane. :-) > For some reason (inexperience probably, or a bad > article), it was set-up so that both the uid and pwd > were set as session variables, and EACH PAGE on the > site checked the uid & pwd against the database... > this seems like a lot of overhead to me. This seems superfluous to me as well. So, you are saying that the unique identifier and the password are stored on the server in the session data store (/tmp/sess_$PHPSESSID by default) and validated against the user data store (where the username and password are typically stored) for each access? This offers no benefit that I can think of, because you are validating server data against server data. It does nothing to validate the client data, namely to offer assurance of the client's identity. It is the client that I generally mistrust, not the server. :-) > Here's what I'd like to do: > > login page validates user, and registers > $_SESSION['uid'] (and any others I need, like admin = > true) > > then, all other pages on the site will just need > session_start(); This will work fine and at least seems like a better approach than the old code you found. One thing you might want to consider is what might have been the intent of the old code, which is to add some extra authentication for the client's identity. My reason for suggesting this approach is based on the following: 1. PHP uses a cookie for client identification by default. 2. IE versions 4.0 - 6.0 allow any Web site to read any of the user's cookies, regardless of the access restrictions placed on those cookies. 3. A majority of Web browsers in use identify themselves as being a version of IE between 4.0 and 6.0. Thus, impersonation is quite easy if the cookie is trusted. There are many creative things you can do to add a bit of strength to the identification process. One example would be to store the user agent string in a session variable after authentication and to check the client's user agent for each access within that session thereafter. This would at least force an imposter to replicate the user agent. Yes, this may not be very reliable either, but perhaps it will give you some ideas. Just try to make it hard on the bad guys and easy on the good guys, and you'll probably be fine. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
