--- 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
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.


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to