[Zope] forms: copying objects from request to request

[Chris McDonough]

Jim Penny says:

> 1) heavier machinery:
> You have to have a per-user repository for sessions.  A user can have
> an arbitrary number of sessions open at once (multiple browser windows).
> That means the session data can be very large.  And that tends to
> require external databases.  External databases and zope play very
> nicely together indeed, but it is an additional requirement.


The way Zope 2.5 sessions work, if you use cookies, each user only has 
one session namespace no matter how many browser windows he/she has open.

That said, it's true that session data can be large.  The default 
session storage is RAM-based so it's a bad idea to store lots of stuff 
in it.  But you can put an instance of Zope's transient object container 
into any storage you like -- even one that is persistent, like the 
"main" FileStorage.

> 2) policy problems:
> Each use can have an arbitrary number of sessions open.  HTTP does not
> signal when a session should be closed, sessions are thus held in a
> frozen, and often useless state if a user abandons a session without
> logging out.  This gives you one of two choices -- to time out a
> session after some amount of time, or to delete all sessions on login.
> [Logout is more natural, but you have no guarantee that logout will ever
> occur (the user may simply leave, or the browser crash, etc.)].
> Arbitrary timeouts are guaranteed to hurt someone, some time.  Login is
> more interesting, but makes session recovery after a crash more
> problematic.


Session policy under 2.5 is one of "data expires after so many 
(configurable) minutes of disuse or at the developer's command."  This 
is typical of most sessioning systems.


> 3) Session IDs:
> You have to grant a session ID.  How can it be stored?  In hidden data! 
> (Or in the functional equivalent of a cookie.)
> And unless you are encrypting all traffic, these can be
> sniffed while on the network.  This gives a patient attacker plenty of
> opportunity to assume a session by simply responding to the request more
> quickly than the actual user.  This is something the user is likely to
> "see", but, I suspect something the user is not likely to report.
> That is, in some sense, sessions reduce to hidden variables.


Sure.  It's not a good idea to rely on Zope's browser ids as keys which 
protect information which is actually stuff that you'd want to protect 
with authentication of some kind (like addresses, and god forbid, credit 
card numbers).


> Look, HTTP is stateless, by design.  Sessions are stateful, by design. 
> A stateless and a stateful system are bound to react in odd ways when 
> used together, at least sometimes.


I think of it as sessions trying to lend state to a stateless system. 
They are indeed a "hack" but they provide a uniform API that at least 
lets people pretend there's some state, which makes things a bit easier 
to think about in practice.

> Recap:  use sessions when you have a lot of data to transfer across
> forms.  Use hidden variables when you have small amounts to move.
> Sessions are often more secure in practice, not because they are
> inherently a better idea, but because session authors have often 
> thought the problems through.  In either case, if security is a 
> concern, the sessionID and/or any hidden variables should be protected 
> using a digital signature.  If you use sessions, be sure that you 
> understand and document the session expiration policy.

I agree:  don't rely on sessions or hidden form fields to securely 
maintain state with sensitive information unless you're communicating 
over SSL.

- C