Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: > > I built and use a module that encodes a session hash into a > > number of hidden fields with a security MD5 sum. > > Sounds a lot like CGI::SecureState. Have you ever looked at it?
I just installed and played with CGI::SecureState (using the example in the POD) and it is totally different than my module. When I used CGI::SecureState it gave the client a non-versioning (more on that later) key and stored the state information in the filesystem. My module doesn't need to store any information in a database or in the filesystem. The entire state is given to the client in hidden form fields, and is passed back to the server on the next request. In addition, CGI::SecureState does not tie the state information to the *page*. With my module (or any method that stores the *data* in a hidden form field, not just a non-versioning key), state information is tied to the page. Let me explain: Imagine a multi-step order process where the user works through pages A, B, C, and D, (which contain forms) then uses the back button to go back to page B, changes the form values, and submits the form. With CGI::SecureState, page C will receive the state information stored by page D (that was intended for use by page E, we presume), instead of the state originally stored by page B (that was intended for page C). This is because all the pages share the same key, and old "versions" of the state are overwritten by the new "versions" and no longer available. When the back button is hit, a newer version of state may be used where an older version was intended. With my module, page C always gets the state information stored for it by page B, since the state is stored in hidden form fields in page B. The browser is actually storing the state and will always submit that same state to page C. (I have mentioned that CGI::SecureState uses a non-versioning key a few times. A way to make CGI::SecureState tie the state information to the actual page would be to change the key whenever the state changed, thus creating a versioning key. The key could be a hash of the state itself. This potentially means that a huge number of versions of the state would have to be stored on disk. I think this method would only be helpful if the state is large and it's not acceptable to pass it back and forth between the client.) In addition, CGI::SecureState gets fuddled if the user opens a new window (something I do often) and then starts performing different operations in each window using the same state key! It has no way of knowing a new windows exists and generating a new key. If you just store a customer id, customer name, and other rarely changing information in the state, these concerns may not matter to you. If you break a long form or order process into multiple pages, gathering new information on each page and storing it in the state so that you can process the order at the end, then this is a likely problem. David
