[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposing Section 508 compliance as requirement for 2.x



On Thu, 2007-04-26 at 10:12 +0100, Ed W wrote:
> As an aside, whilst I am not saying that it's impossible to do this
> all 
> with only sessions, I am actually baffled as to how it could be done
> and 
> need to do something similar in another project.  So if someone can 
> describe how to have multi-window state kept using only sessions then 
> please let me know... (I can't see how to do it without having a 
> session_id in the URL in order to figure out which window is
> submitting 
> each time??)

I think what you looking to do is something like the CGI::Application
plugin CGI::Application::Plugin::FormState

http://search.cpan.org/~mgraham/CGI-Application-Plugin-FormState-0.12/

Basically it uses 2 ids, a session id and a form state id. This
particular implementation stores the form state in a server side session
leading to session bloat very quickly.

What I would prefer to see is something like:

At session creation time generate a random secret and store it in the
server side session. _NEVER_ send it to the client.

Then for form state bundle it all up (URL encoded string? Storable?) and
base64 encode it. Then put in a hidden form variable
"$base64_state:sha1_base64(\"$base64_state$session_id$session_secret
\")". Then when the form is submitted you can verify the form state by
comparing the hash that was submitted to a newly calculated hash using
the submitted state and the secret from the server side session. ie.

($submitted_state, $submitted_hash) = split /:/, $cgi->{form_state};
if( $submitted_hash eq sha1_base64("$submitted_state$session_id
$session_secret") ) {
  # Good state
} else {
  # Hack attempt
}

-- 
Tony Fraser
..hidden..
Sybaspace Internet Solutions                        System Administrator
phone: (250) 246-5368                                fax: (250) 246-5398