On Mon, Jan 28, 2002 at 08:09:15PM +0100, Joachim Werner wrote:

Hi!

...

you must use a hidden form in DocumentB to transport your variable x from DocumentA to DocumentC.

The more elegant solution is using sessions for that. Like SmartWizards do for example.

You'd just store the REQUEST variables you'll need with (in DTML)

<dtml-call "SESSION.set('x', REQUEST.['x']">.

Hidden forms work fine, but they are a hack. In some cases they even are a security risk: Anybody can open your HTML file with a text editor, manipulate the hidden form values and post the form.

Well, to my mind, sessions are also "just a hack". The problem with sessions is that they require heavier machinery to support, a policy (which is certain to be wrong) about when the session is closed, and a session key, which is as valuable to a determined cracker as the hidden fields are. But lets take these one at a time: 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. 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. 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. 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. Mind you, I am not blindly opposed to sessions; they sometimes make a great deal of sense, and I use them myself. If you have a LOT of data to transfer and several layers of forms, they can make life much easier, as the data does not have to be remarshalled into each form. Also, note that it is not hard to protect hidden variables, people just seldom do. For example, you could take a secret, concatenate the hidden values and calculate a SHA signature of this string. The server sends the hidden variabls, as usual, and also sends this SHA as an additional hidden variable. Now when the server gets the form back, it performs the calculation again. If the returned SHA does not match the newly calculated SHA, then the hidden variables have been tampered with and should be rejected.

I saw this once with a form that changed a user's password. It held the user roles in a hidden form field. So the user could have just sent the form with "Manager" added to the hidden form field to get full system access ...

See above paragraph. 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. Jim Penny

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