> Could you explain how this could be accomplished, because I'm not
> understanding how to do it.
> As I understand HTTP Authentication (correct me if I'm wrong), the
> user's computer still has to send a 'username/password' pair to perform
> the authentication. I can't see how this could be used to maintain
> session data.
> But maybe my mind is just trapped in a rut. Please enlighten me.

The problem here is not where to store the session data.  That's obvious.
You store the session data on your server.  The real problem is linking
the session data (ie. the contents of a shopping cart) to a specific user
so when that same user is surfing through your site, on every request you
know which cart is his.  And if he goes away and comes back later, you
again can go find his cart and you know what is in it.

Ergo, therefore, if you are able to uniquely identify the user you have
solved your session problem.  HTTP Authentication does this brilliantly.
The only difference between cookies and http auth is that with a cookie
you send the remote user a unique identifier that is then sent back to you
whenever that specific user visits your site.  Because this happens
automatically and people don't like that, some people turn this off.
With HTTP authentication, instead of doing this automatically you have the
user create a profile on your site where part of this will include a
unique identifier and a password.  Each time the user visits your site
this information will be sent exactly like a cookie.  Depending on how
users configure their browsers they may have to log in at the beginning of
a session although these days most browsers have these password managers
that make this login procedure trivial.


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

Reply via email to