Sune B. Woeller wrote:


hi David,

I had the same problem, see this thread with a workaround,
and this bug report: http://www.zope.org/Collectors/Zope/1594

regards,
Sune B. Woeller

David H wrote:

Hi List,

I am curious about the SESSION.invalidate() method.

This code sets a SESSION key and value and then calls SESSION.invalidate():

<tal:block define="dummy python:request.SESSION.set('Dodgers','Baseball')" />

<p> before invalidate </p>
<p tal:content="python: request.SESSION" />

<tal:block define="dummy python:request.SESSION.invalidate()" />

<p> after invalidate()</p>
<p tal:content="python: request.SESSION" />

Produces this output:

before invalidate
id: 11125588150079827980, token: 95966850A1xaz-gQYlU, contents: [('Dodgers', 'Baseball')]


after invalidate()
id: 11125588150079827980, token: 95966850A1xaz-gQYlU, contents: [('Dodgers', 'Baseball')]


It seems that SESSION.invalidate() does not take immediate effect.
Seems like a developer could getinto trouble if the same script *both* does
SESSION.invalidate()
SESSION.set('something','somevalue').


Because after the script runs 'something' goes away when invalidate() finally
occurs.


And is the effect described above to be expected or do I have this wrong?

Thanks,
David


Sune,

Thats great! Thanks.


My tests confirm this excerpt from Collectors/Zope/1594: 'The suggestion ... 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 :)'

David


_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to