On Tue, 01 Aug 2006 19:10:23 +0200, Manlio Perillo email@example.com wrote:
Not really unless you want your system on its knees begging for some holidays. Just think about the chance for 1M people to visit your website each day. Your sessions database will shortly be the biggest bottleneck of the application.
But then why store sessions in a database at all?
Beucase registered users that are logged in and required to be remembered are asking for that. Persistent sessions persist even after reboots of the application something that may happen in 2 weeks time.
Yes, I know. I was searching for an object with the "right" lifetime, forgetting about the request.
context lifetime is ending soon.
By the way: what's the difference beetwen ctx.remember/locate and storing attributes on the context/request?
Too long and complicated to explain and not worth it. but storing data on the request is always a bad idea. And storing data on the session is mostly a bad idea. Storing data in the database is not a bad idea.
Sorry, I did not noticed that it was a callback! Only a question: sessionwrapper is self.guard?
what is self? anyway I guess yes, searching for the place where loggedIn is called is a much easier way to find the answer.
I think that serverside state is not needed here, cookies come for this.
Cookies come to identify all the requests coming from the same browser, they are not meant to store server side state, although they can keep 32k of data.
Sometimes one only needs to know the authenticated username (to personalize some portions of a page).
This is something that is already available to authenticated users. I think you mean un-authenticated users here.
Another use cases can be to have the login and logout page as fixed resource (and, maybe, on a SSL connection).
This solution needs a custom, but I can reuse your SessionManager interface!
Not really. You need to change SessionWrapper to do that. And only the locateChild method.