[Zope] Re: Invalidating a session, creating a new

[Sune Broendum Woeller]

> -----Original Message-----
> From: zope-bounces at zope.org [mailto:zope-bounces at zope.org]On Behalf Of
> Tres Seaver
> Sent: 23. november 2004 22:37
> To: zope at zope.org
> Cc: Sune Broendum Woeller
> Subject: [Zope] Re: Invalidating a session, creating a new
>
>
> Chris McDonough wrote:
> > On Tue, 2004-11-23 at 15:07, Dieter Maurer wrote:
> >
> >>Sune Broendum Woeller wrote at 2004-11-22 20:43 +0100:
> >>
> >>>...
> >>>
> >>>>>>In the zope book, sessions chapter, is written:
> >>>>>>
> >>>>>>"Manually Invalidating A Session Data Object
> >>>>>>
> >>>>>>Developers can manually invalidate a session data object.
> >>>>
> >>>>When a session
> >>>>
> >>>>>>data object is invalidated, it will be flushed from the system,
> >>>>>
> >>>>>and will not
> >>>>>
> >>>>>>be returned by subsequent references to REQUEST.SESSION or
> >>>>>
> >>>>>getSessionData().
> >>>>>
> >>>>>>"
> >>>>>>
> >>>>>>and :
> >>>>>>
> >>>>>>"...subsequent references to REQUEST.SESSION in this same
> request will
> >>>>>>return a new session data object."
> >>>>>>
> >>>>>>I would like to be able to invalidate the session object, and
> >>>>>
> >>>>>then create a
> >>>>>
> >>>>>>new session with a new key, to be accessed in the next request.
> >>>>>>
> >>>>>>But I find that when invalidating a session data object, I
> can *still*
> >>>>>>access the old session data in subsequent references to
> >>>>>
> >>>>>REQUEST.SESSION, in
> >>>>>
> >>>>>>the same request that is. I do not get a new session data
> object, as I
> >>>>>>should according to the zope book. And therefore I can not
> >>>>>
> >>>>>reference the new
> >>>>>
> >>>>>>keys I create in the following requests.
> >>>>>>
> >>>>>>Has anyone got a solution for this problem ?
> >>>>>>
> >>>>>>It seems the invalidation goes on "between" requests.
> >>>>>>
> >>>>>>Is this an error with the sessioning machinery or in the zope book ?
> >>
> >>Maybe, it worked in some Zope version.
> >>But, it has no chance in a modern Zope:
> >>
> >>  Sessions are created on demand, i.e. when you access the
> >>  SESSION object for the first time.
> >>
> >>  To make this happen, the "SessionDataManager" registers
> >>  a factory as a REQUEST lazy item under the name "SESSION".
> >>
> >>  When you access "REQUEST.SESSION", the factory is called
> >>  to get the real session object and then the session object
> >>  is stored as normal REQUEST variable. The factory is removed
> >>  form REQUEST (as the implementors thought it were no longer
> necessary).
> >>
> >>With this description, you can see: you can invalidate the session
> >>object but this has no chance to give you a different session object
> >>(in the same request).
> >>
> >>You would need to change the handling of lazy items
> >>in "ZPublisher.HTTPRequest.HTTPRequest" (not allowed
> >>to remove the factory) and delete the "SESSION" as normal
> >>REQUEST variable to make it work.
> >>
> >>
> >>I would say, the book is wrong.
> >
> >
> > Darn.  It was meant to work the way it's described in the book.  For it
> > to not work this way is a bug.  The invalidate method of a session
> > should cause the session data object to be invalidated.
> >
> > Unfortunately, the "lazy" resolution stuff in ZPublisher also removes
> > the factory from the _lazies namespace, so if the invalidation removed
> > 'SESSION' from request.other it could also never get it from
> > request._lazies in the same request. :-(
> >
> > It would be good if a tracker issue could be entered about this.
> >
> > In the meantime, a workaround is to not use REQUEST.SESSION to get the
> > session data, but to instead use something like
> > "context.session_data_manager.getSessionData()" to get the session data
> > associated with the current request.
>
> Wouldn't an adequate workaround be just to clear the session (rather
> than destroying it and creating one anew)?  E.g.:
>
>    session = REQUEST.SESSION
>    session.clear()
>    session['key'] = value
>
> Tres.

The suggestion from Tres gets me half the way, but it is
not enough since I need to get a new session id.

The problem is that the request still holds the
old session object.
The suggestion by chris, to use
"context.session_data_manager.getSessionData()"
to get the session after the call to invalidate
works - it gives me a new session object,
and all is well :)

To summarize, this does the trick:
s = context.REQUEST.SESSION
s.invalidate()
s=context.session_data_manager.getSessionData()
s['myNewKey']='myNewValue'



Should I file a bug report here :
http://zope.org/Collectors/Zope
?

regards, and thank you for your help,
Sune