[Twisted-web] [Nevow] about new guard in sandbox

[Valentino Volonghi aka Dialtone]

On Tue, 01 Aug 2006 10:40:20 +0200, Manlio Perillo <manlio_perillo at libero.it> 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.

>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.

>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.

>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.

>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, 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.

>Yes, this is not a valid concern but I like to have code that is as much
>symple as possible, where I don't have to try to understand every
>statement. ;-)

Which is yet another reason to have it like it is now.

>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. The problem rises when you want to reach consistency between all the servers.