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

[Manlio Perillo]

Valentino Volonghi aka Dialtone ha scritto:
> On Tue, 01 Aug 2006 19:49:41 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> Ok, but you can store the session in a global dictionary (as done in
>> your default implementation).
>> The sessions are available, at least if the server is not rebooted.
>>
>> I think that a database should be used only if you want to share
>> sessions beetwen distributed servers (or if you are using a server like
>> Apache).
> 
> This is just wrong. Persistent sessions are useful exactly to avoid
> re-creating them when rebooting the application.
> 

And what's the problem?
Hopefully you are not going to reboot the server every week, and users
can always relogin.


>> No, I meant storing data that shoud be stored for the "lifetime of the
>> rendering".
>>
>>
>> As done in formal with the forms data and errors.
>> Where should be this data stored?
> 
> It shouldn't. Pass it through the callee.
> 

Ok, but this means that *every* current application should be rewritten...

>> The request object is not good?
> 
> Not in its current shape and most probably not at all.
> 

Ok.

>> So sessionwrapper parameter is not needed?
> 
> The guard attribute is on the Session not on the SessionManager 

Ok, but you pass a session to the loggedIn method.
So you can do (if I'm not wrong):

def loggedIn(self, session, request):

    if request.args.get('rememberMe'):
        session.guard.makePersistentCookie(session, request,
max_age=self.sessionPersistentLifetime)
        self.makePersistentSession(session)


> [...]
>
>> Yes, but guard requires a lot of "things" to happen for every request.
>>
>> I would like to do some benchmark, but if I only need to know the
>> authenticated username, maybe I have no need for a session wrapper (but
>> I need the session manager).
> 
> You might just avoid using cred/guard entirely and write your own thing
> if you like... guard is not meant to work without cred yet you were
> proposing to rely on the avatarId which is an internal cred thing.
> 

confusing avatarID was a my error...

> Anyway I'd be curious to know how you are going to implement cred
> integration without a SessionWrapper like resource with the current
> interface.
> 

Of course there will be no cred integration ;-).

I don't want (still) to use guard because there are a lot of things that
I do not understand.

Like support for multiple portals, setResourceForPortal and so.

Every time I think I'm beginning to understand, it suffice to read some
code (as Weever or Stiq) for understanding that I do not understand ;-).


Thanks and regards   Manlio Perillo