A possible solution: the postrun callback for ProtectCSRF runmodes could be
enhanced to detect that ValidateRM was used, and there were errors on the
form. Something like this:
if($self->can('dfv_results')) { # hmm, using CAP::ValidateRM
my $r = $self->dfv_results;
if($r->has_missing or $r->has_invalid) {
# the form has errors, assume we need to generate an new CSRF
token:
# ... code here to generate a new token and add it to the HTML
...
I'm not sure if a new token should be generated, or the existing one should
be (re)used. At a minimum, the hidden field with the token needs to be
added to the HTML again.
For CA apps that don't use ValidateRM, we could add a new method to
CAP::ProtectCSRF that would set some kind of flag so that the postrun
callback would know to generate a token and add it to the HTML. The app
developer would have to remember to call it though -- it wouldn't happen
behind the scenes like above. Something like this:
sub create_check : Runmode :ProtectCSRF {
my $self = shift;
# check the form without using my ValidateRM
$self->add_csrf_id_to_html();
# and maybe $self->generate_csrf_token();
# ... code to re-generate the original form with errors ...
} <--- the postrun callback/hook would do the real work, if the flag was
set
Comments?
-- Mark
On Thu, Dec 3, 2009 at 1:16 AM, Mark Rajcok <[email protected]> wrote:
> Anyone see a solution to this problem? (other than abandoning attribute
> handlers and requiring functions like create() above to explicitly call
> _publish_csrf_id() and _add_csrf_id())
>
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
