Hi Hubert, * hubert depesz lubaczewski <[EMAIL PROTECTED]> [2007-03-13 10:10]: > but. after this "named" user will logout, or close the browser > and reopen - we should be able to go back to the previous > "anonymous" user.
just to add a different voice: this approach seems perfectly sensible to me. In fact, it seems like a very good idea. The only problem I see is that you may get a lot of spurious sessions from registered users hitting the site before they head to the login form. You should probably avoid creating sessions until the user actually changes his settings or otherwise does something that requires saving data about him on the server. Another option is to not create server-side sessions for these users at all – just store all their settings in their cookie. Oh, also: when an anonymous user decides to register, his anonymous session data should be promoted to his account, and then the anonymous session deleted. > 1. do you see any problems with this approach? No. It’s the first thing I thought of as well, and after thinking about it for a few minutes, I can’t see any reason why it should cause a problem. The only difference is that I would use two different cookies for the two kinds of access instead of saving the anonymous session ID to a backup cookie on login. Just check for both cookies when handling requests, preferring the logged-in session cookie when it exists. It doesn’t change the app’s complexity, adds only an extremely marginal amount of extra processing for anonymous sessions, but it makes the protocol ever so slightly simpler and more robust. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
