At 12:34 PM +0000 3/11/08, Stut wrote:
On 4 Mar 2008, at 13:57, Jochem Maas wrote:
Stut mentioned a little while back that he avoids using the built-in session
mechanism if at all possible, but still manages to track user state ... now I
can think of a way or two that he might do that but I was wondering if
any one could give an idea about the write way to do it in terms of
high performance :-)
Finally found time to finish the article, sorry for the delay...
http://stut.net/articles/sessionless_sessions.html
Constructive criticism welcome.
Stut:
Nice article.
I'm currently working on one large site and I only pass the user's id
from page to page in session. All other data is pulled from the
database as needed. But, I've never had a problem that spanned
several servers. The idea was simply to call-in for the data needed
rather than carry baggage around.
I have noticed that eBay uses a similar technique for different
states of a user (un-confirmed, revisiting, and confirmed) via a
cookie.
I question the reason why you would want to encrypt the cookie
considering that before the user is going to be provided access to
sensitive data that you require a password confirmation. The
encryption seems to be an unnecessary overkill.
So what if a malicious user uses a cookie to pretend to be a real
user IF before they can get access to sensitive data they have to
enter a correct password?
Please explain.
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
