On 3/14/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
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.
of course.
Another option is to not create server-side sessions for these users at all – just store all their settings in their cookie.
not really possible as the site will store information per-user in database.
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.
of course :)
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.
looks sane to me. can you point me to a direction (manual/webpage/example) where i can read about setting session object from 2 different cookies? i.e. with some logic about which session_id to choose. depesz -- http://www.depesz.com/ - nowy, lepszy depesz _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
