[Twisted-web] Re: /__logout__ doesn't expire the session

Andrea Arcangeli andrea at cpushare.com
Thu Jan 13 16:06:53 MST 2005


On Thu, Jan 13, 2005 at 04:12:22PM -0500, Alex Levy wrote:
> Maybe this could be in an example somewhere, because I (for one) can't 
> figure out how to do it. How do you access the session from the logout 
> function? It isn't called with any parameters, and from what I can tell 

This is indeed the problem.

I even setup a meaningful login function in the root page instead of the
noLogin of most examples:

				if avatar_id is checkers.ANONYMOUS:
					resc = guest.root_page_class()
					resc.realm = self
					return (inevow.IResource, resc, resc.logout)
				else:
					resc = account.root_page_class(avatar_id)
					resc.remember(avatar_id, iweb.IAccount)
					resc.realm = self
					return (inevow.IResource, resc, resc.logout)

problem is that the implementation in the root page is like this:

	def logout(self):
		return None

So it doesnt' get that far.

I'd actually prefer to get a callback so I can truly trap the event, but
I need some way to reach the ctx to do the cleanup. I understand the
twisted auth part must not know anything about the ctx, that's nevow
stuff, but we should find a way to pass the ctx parameter (in a opaque
way from twisted point of view), from nevow to the logout callback.

Now, I don't claim this is really necessairly a relevant problem, if one
is careful and never uses a certain interface from the session in the
guest part, then there's no risk, but if you use it somewhere
(incidentally a page shared between the account and the guest sections),
then there can be a problem.

I may even be ok to code carefully and never share an interface between
guest and account, it's not that bad if you keep it in mind and you make
sure not to share interfaces that attaches to the session, it's possible
to code it safely, but I just feel safer and relieved from the pain of
having to check everything by myself, if it was automatically expired by
logout. So if I do a mistake I will get an exception or anyway I don't
risk exposing sensitive data to the same session but outside the account
area (i.e. after logout). So I've no doubt I feel safer expiring the
session completely even if that means a bit more of traffic for cookie
regeneration. I'd be fine to do it by hand with a callback though (and
if somebody else wants to be more optimzied but less obviously safe, he
can use the unsetComponent in the same callback where I do the expiry).

> The architecture is good, it's just not very clear to many end users how 
> to navigate through all the abstractions.

Here it doesn't seem just not clear, it seems not possible without
any change to the caller to do the cleanup in the logout callback.



More information about the Twisted-web mailing list