On Tue, Jan 18, 2005 at 11:30:50AM +0000, Dave Howorth wrote:
> (1) How does CGI::Untaint distinguish between a validation failure and a
> programming error (such as an uninstalled module)? The first should go
> to the browser, the other to the Apache log. The second is definitely an
> exception, but one could consume many pints deciding whether the first
> ought to be.
A validation failure is a very late check that occurs even after the
regex check. They're both handled differently in the code. The
uninstalled module problem will be caught much earlier.
> (2) (largely a Maypole problem) By default, Maypole doesn't show those
> errors (which was why I didn't spot it earlier :) but even when you
> change the template so it does, it doesn't associate fatal errors with
> the field that caused them. CGI::Untaint is using a different method to
> report handler error messages and its own default error messages.
I may be missing something, but that's not an Untaint issue as much as
an issue with how you call untaint. You only ever call untaint on one
parameter at a time, so the application can trivally associate the error
with the field.
> It's also not how it's supposed to work, according to the docs. is_valid
> is supposed to return a false value if validation fails, and
> CGI::Untaint's error method is supposed to return the message:
> "my $error = $handler->error;
> If the validation failed, this will return the reason why."
Which is what happens. If we don't know why, we give a default error. The
docs are missing the fact that you can throw your own execption here to
provide a custom error message, but what happens doesn't contradict the
docs AFAICS.
Tony
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT