[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposing Section 508 compliance as requirement for 2.x
- Subject: Re: proposing Section 508 compliance as requirement for 2.x
- From: Tony Fraser <..hidden..>
- Date: Fri, 11 May 2007 10:52:28 -0700
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