To complete this one-man dialogue, the code below seems to work well, but I
had to change the if statement to
if(defined $self->{'__DFV_RESULT'}) {
to guard against a scenario where CAP::ValidateRM is loaded, but neither
check_rm() nor validate_rm() was called (i.e., ValidateRM was not used to
validate the form). In this scenario, dfv_results() calls 'die' -- not
good.
I assume this is a bit chummy -- a module shouldn't be looking at another
module's "private" data -- but there is no method in CAP::ValidateRM that
indicates if check_rm() or validate_rm() was called.
I ended up writing my own CSRF Plugin. It borrows some good ideas from
ProtectCSRF in that it uses attribute handlers and adds the hidden form
field to the HTML. If I ever decide to put it up on CPAN, maybe then I'd
ask Mark S. to add a new method to CAP::ValidateRM.
-- Mark
On Thu, Dec 3, 2009 at 9:29 PM, Mark Rajcok <[email protected]> wrote:
> A possible solution: the postrun callback for ProtectCSRF runmodes could
> be enhanced to detect that ValidateRM was used, and that 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
> ...
>
##### 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/ ##
## ##
################################################################