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

[Manlio Perillo]

Valentino Volonghi aka Dialtone ha scritto:
> 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.
> 

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