Simple validation of cgi parameters and runmodes.
# given the following CGI parameters:
# op=add_item; name=William Blake; ssn=345-21-6789; crackme=$ENV{EVIL_MEAT};
use CGI::ValidOp;
my $cgi = CGI::ValidOp->new({
add_item => { # using full syntax
name => {
label => 'Name',
checks => [ 'required', 'text::words' ],
},
ssn => {
label => 'Social Security number',
checks => [ 'demographics::us_ssn' ],
},
},
remove_item => { # using shortcut syntax
ssn => [ 'Social Security number', 'required', 'demographics::us_ssn' ],
confirm => [ 'Confirmation checkbox', 'required', 'checkbox::boolean' ],
},
cgi_object => new CGI($fh),
});
my $name = $cgi->param( 'name' ); # eq "William Blake"
my $ssn = $cgi->param( 'ssn' ); # eq "345-21-6789"
my $crackme = $cgi->param( 'crackme' ); # is undef; it was removed by the check
my $confirm = $cgi->param( 'confirm' ); # is undef; it doesn't exist
my $op = $cgi->op; # eq "add_item"
my @errors = $cgi->errors; # eq ( 'Parameter "crackme" contained invalid data.' )
my %vars = $cgi->Vars; # eq (
# name => "William Blake",
# ssn => "345-21-6789",
# crackme => undef,
# )
CGI::ValidOp is a \s-1CGI\s0 parameter validator that also helps you manage runmodes. Its aims are similar to Perl's: make the easy jobs easy and the complex jobs possible. \s-1CGI\s0 parameter validation is boring, and precisely for that reason it's easy to get wrong or ignore. CGI::ValidOp takes as much of the repetition as possible out of this job, replacing it with a simple interface.
There are many \s-1CGI\s0 parameter validation modules on \s-1CPAN\s0; why on earth would I write another one, and why should you use it? Before writing ValidOp I made a list of requirements and checked all available modules against it, hoping that even if nothing matched there'd be a project which I could subclass or contribute to. I didn't find anything. Here's what I think ValidOp does right:
In addition to validating parameters, CGI::ValidOp has a number of methods for dealing with runmodes (henceforth referred to as 'ops'). In fact, the 'op' concept is key to ValidOp's advanced usage: parameters are defined as children of ops. A \*(L"display_item\*(R" op may need only a numeric id, while an \*(L"add_item\*(R" op will take several parameters. All these can be defined once in a single location.
You can change the validation defaults for the entire app, all parameters for one runmode, or per-parameter.
Parameters can be accessed just like with \s-1CGI\s0.pm: param for individual parameters and Vars for all of them.
While error message must be available globally, having per-parameter error messages is an important usability improvement. When returning a long form page to a user, it's good to show them error messages where they're most useful.
ValidOp is test-driven, object-oriented Perl.
If you're going to trust someone else's code for security purposes it's nice to have proof that it works. CGI::ValidOp has an extensive test suite that checks every part of its operation, particularly the validation routines. I keep the current version running at <http://sonofhans.net> validop with a full test page. If you can produce unexpected output, file a bug report.
Creates and returns a new CGI::ValidOp object. The initializing hashref is optional. If supplied, it may contain two types of values: configuration options and runmode definitions. Configuration options must be prepended with a dash (\*(C`-\*(C'); runmodes must not be.
Setting 'cgi_object' will allow you to override the \s-1CGI\s0 object that would be provided by default, if say, you needed to use this module under mod_perl.
my $cgi = CGI::ValidOp->new({ -allow_unexpected => 0, # configuration option add => {}, # op, or runmode definition );
See Configuration and \*(L"Runmode Management\*(R" for more details. \*(C`param\*(C' behaves similarly to the \s-1CGI\s0.pm method of the same name, returning the value for the named parameter. The differences from \s-1CGI\s0.pm's \*(C`param\*(C' are:
The return value will be validated against all defined checks.
The return value will be untainted if the checks require it.
Any necessary error messages will be created.
The \*(C`\@checks\*(C' arrayref is optional. If supplied, it replaces all previously defined checks for the parameter and overrides all defaults. An empty arrayref (\*(C`[]\*(C') will give you the parameter as input by the user, unchecked; it will still be tainted.
\*(C`Vars\*(C' behaves similarly to the \s-1CGI\s0.pm method of the same name, returning the entire parameter list. In scalar context it returns a hash reference; in list context it returns a hash. The differences from \s-1CGI\s0.pm's \*(C`Vars\*(C' method are:
Multivalue parameters are returned as an arrayref, rather than a null-byte packed string.
The runmnode_name parameter (\*(L"op\*(R" by default) is not returned; see op for more details.
Unexpected parameters are not returned (see allow_unexpected).
Parameters that failed one or more checks are returned as \*(C`undef\*(C'.
In scalar context the hashref is not tied, and changes to it do not affect the parameter list.
Returns the current runmode name. In the normal case, this is the \s-1CGI\s0 parameter given for \*(L"op\*(R" (but see runmode_name). Several factors affect the return value:
If a runmode parameter is given but it doesn't match the name of any defined runmode, \*(L"runmode aliases\*(R" are searched.
If no \*(L"runmode alias\*(R" matches, the value of default_op is returned.
Note that while ValidOp doesn't require you to use its runmode management features, it still uses them internally. Even in the of no defined parameters or runmodes, ValidOp uses \*(L"default\*(R" as its runmode and all parameters are subsidiary to it. This is invisible to the user.
Returns an arrayref of all error messages for the current parameter list and parameter definitions. Returns \*(C`undef\*(C' if there are no errors. Returns the CGI::ValidOp::Op object for the current runmode, or the runmode given. See \*(L"Op Objects\*(R" for more details, or the documentation for CGI::ValidOp::Op for all the details.
Resets the parameter list to the given hash reference.
ValidOp has a number of configurable options which alter its behavior. These options can be given in the constructor, via accessor methods, or both:
my $cgi = CGI::ValidOp->new({ -allow_unexpected => 0, -default_op => 'home', });
$cgi->default_op( 'view' ); # overrides 'home' above
Default: 1. Accepts: 1 or 0. Controls whether ValidOp accepts incoming \s-1CGI\s0 parameters which you have not defined. If true, all incoming parameters are accepted and validated. If false, parameters you have not defined are ignored.
Default: 0. Accepts: 1 or 0. If true, will not return any data for a parameter not received in the query string. ValidOp's default behavior is to return an \*(C`undef\*(C' value in this situation.
Default: 'default'. Accepts: word. The default runmode name. If no runmode parameter is given, or if the runmode given does not exist, the runmode specified here will be used. See \*(L"Runmode Management\*(R".
Default: 1. Accepts: positive integer. Passed through to \s-1CGI\s0.pm when getting parameters. See \s-1CGI\s0.pm.
Default: undef. Accepts: array. Text with which to surround parameter labels in error messages. If given a single scalar, it is inserted both before and after the label. If given an arrayref, the first value is inserted before and the second is inserted after.
Given an error message of \*(C`$label is required.\*(C' and a label of \*(L"Confirmation checkbox,\*(R" ValidOp would normally output \*(C`Confirmation checkbox is required.\*(C'. Here's how various values affect the error message:
$cgi->error_decoration( '"' ); # "Confirmation checkbox" is required.
$cgi->error_decoration( '* ', undef ); # * Confirmation checkbox is required.
$cgi->error_decoration( undef, ':' ); # Confirmation checkbox: is required.
$cgi->error_decoration( '<strong>', '</strong>' ); # <strong>Confirmation checkbox</strong> is required.
Default: 25,000. Accepts: positive integer. Passed through to \s-1CGI\s0.pm when getting parameters. See \s-1CGI\s0.pm.
Default: 'op'. Accepts: word. The name of the runmode. ValidOp treates the runmode parameter differently from other parameters; see \*(L"Runmode Management\*(R" for more details.
These routines control what values are returned by \*(C`Vars()\*(C' and \*(C`param()\*(C'. They are mutually exclusive, and have the following order of precedence:
on_error_return_undef
on_error_return_encoded
on_error_return_tainted
In other words, if both \*(C`on_error_return_undef\*(C' and \*(C`on_error_return_tainted\*(C' are given as true, \*(C`on_error_return_undef\*(C' will apply.
on_error_return_undef
The default behavior. Values which fail validation are ignored, and returned as \*(C`undef\*(C'.
on_error_return_encoded
Values which fail validation are returned as input, but first encoded with HTML::Entities's \*(C`encode()\*(C' method.
on_error_return_tainted
Values which fail validation are returned unchanged. Don't do this.
When constructing a CGI::ValidOp object, you may pass a \*(C`-checks\*(C' option. The default checks are: \*(C`['text']\*(C'.
When defining an op within the CGI::ValidOp constructor, you may pass a \*(C`-checks\*(C' option.
When defining a param within the op definition, you may pass a \*(C`-checks\*(C' option.
When calling the \*(C`param\*(C' method, you may pass an array reference as the second parameter. This arrayref is passed straight through to the parameter's \*(C`checks\*(C' accessor.
Copyright (c) 2003-2005 Randall Hansen. All rights reserved.
This program is free software; you may redistribute it and/or modify it under the same terms as Perl itself.
See http://www.perl.com/perl/misc/Artistic.html
Randall Hansen <[email protected]>
Chad Granum <[email protected]>