> 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. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
