Valentino Volonghi aka Dialtone ha scritto: > On Tue, 01 Aug 2006 10:40:20 +0200, Manlio Perillo > <[EMAIL PROTECTED]> wrote: >> Only a question: in the example you only store (in the database) >> "permanent" sessions. >> Not sure about this, but I think that all sessions, except those for >> anonymous access, should be persisted in the database (to avoid problems >> in a distributed system). > > 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? >> Here I'm not sure to understand. >> You mean that the avatarID (username) is not stored in the session >> object? This seems not the case. > > First of all the avatarID is not the username. The avatarID is the > avatarID. Then I repeat that I do not store the avatar anywhere which > means that I have to pass through portal.login() for each request and > portal.login() requires full credentials. Then I cannot get the avatarId > because it is only passed to requestAvatar and the SessionWrapper only > sees the result of that call. > Ok, I missed this. >> Another thing: is it really necessary to create a session for anonymous >> access? > > This is an interesting question. I think I'll probably say yes. > I will do some tests. >> And what about to store the authenticated username in the context >> (instead of hacking on the site.makeSession)? > > Maybe you didn't notice but... The context is going away we have been > talking about this for ages and using the context means that the code > will need to be trashed in not so long. > Yes, I know. I was searching for an object with the "right" lifetime, forgetting about the request. By the way: what's the difference beetwen ctx.remember/locate and storing attributes on the context/request? >> I'm against this because I whould like to have a realy reusable >> SessionManager. >> >> The SessionManager is really an useful class and it should not depend >> over a SessionWrapper (because I can choose to not use a SessionWrapper >> al all). > > And what does this have to do with the loggedIn method? The reason it is > like that is because cookies are dealt with in the sessionwrapper and > not in the sessionmanager, Of course! > but having 2 places to check the rememberMe > argument was sub-optimal. If you don't need the sessionmanager you can > clearly avoid implementing loggedIn at all, but this doesn't mean the > rest of the developers don't need such a callback. > Sorry, I did not noticed that it was a callback! Only a question: sessionwrapper is self.guard? > [...] >> As an example a valid alternative to store state in the server is to >> store it in the cookie. > >> NEVOW_SESSION="username=manlio&last_accessed=...&created=..." > >> of course using some cryptography. > >> This has the advantage to work "as is" in a distributed system and to >> not depend on the number of sessions/users. > > You will still need a session object on the serverside. Sessions are a > serverside detail and saving state in the database is not hard at all. I think that serverside state is not needed here, cookies come for this. Sometimes one only needs to know the authenticated username (to personalize some portions of a page). Of course having a full dynamic solution like those offered by guard, with cred integration, is a great thing ang I like it. 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! Thanks and regards Manlio Perillo _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
