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