View on
Hans Dieter Pearcey > CGI-ValidOp-0.53 > CGI::ValidOp



Annotate this POD


New  3
Open  0
View/Report Bugs
Module Version: 0.53   Source  


CGI::ValidOp - 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 CGI 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. CGI 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.

Unique features

There are many CGI parameter validation modules on CPAN; 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:

Simple API.
Minimal usage is useful.
Easy to add new checks.
Relation of parameters to run-modes/operations.

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 "display_item" op may need only a numeric id, while an "add_item" op will take several parameters. All these can be defined once in a single location.

Validation defaults settable on many levels to minimize repetition.

You can change the validation defaults for the entire app, all parameters for one runmode, or per-parameter.

CGI integration and compatibility.

Parameters can be accessed just like with param for individual parameters and Vars for all of them.

Per-parameter error messages.

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.

OO and test-driven

ValidOp is test-driven, object-oriented Perl.

Extensive and public test suite.

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 validop with a full test page. If you can produce unexpected output, file a bug report.


new( \%options )

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 (-); runmodes must not be.

Setting 'cgi_object' will allow you to override the CGI 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 "Runmode Management" for more details.

param( $name, \@checks )

param behaves similarly to the method of the same name, returning the value for the named parameter. The differences from's param are:

The \@checks arrayref is optional. If supplied, it replaces all previously defined checks for the parameter and overrides all defaults. An empty arrayref ([]) will give you the parameter as input by the user, unchecked; it will still be tainted.


Vars behaves similarly to the 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 Vars method are:


Returns the current runmode name. In the normal case, this is the CGI parameter given for "op" (but see runmode_name). Several factors affect the return value:

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 "default" 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 undef if there are no errors.

Op( $op_name )

Returns the CGI::ValidOp::Op object for the current runmode, or the runmode given. See "Op Objects" for more details, or the documentation for CGI::ValidOp::Op for all the details.

set_vars( \%params )

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 CGI 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 undef 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 "Runmode Management".


Default: 1. Accepts: positive integer. Passed through to when getting parameters. See


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 $label is required. and a label of "Confirmation checkbox," ValidOp would normally output Confirmation checkbox is required.. 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 when getting parameters. See


Default: 'op'. Accepts: word. The name of the runmode. ValidOp treates the runmode parameter differently from other parameters; see "Runmode Management" for more details.


These routines control what values are returned by Vars() and param(). They are mutually exclusive, and have the following order of precedence:

In other words, if both on_error_return_undef and on_error_return_tainted are given as true, on_error_return_undef will apply.


The default behavior. Values which fail validation are ignored, and returned as undef.


Values which fail validation are returned as input, but first encoded with HTML::Entities's encode() method.


Values which fail validation are returned unchanged. Don't do this.

Defining Checks ^

ValidOp checks

When constructing a CGI::ValidOp object, you may pass a -checks option. The default checks are: ['text'].

Op checks

When defining an op within the CGI::ValidOp constructor, you may pass a -checks option.

Parameter checks

When defining a param within the op definition, you may pass a -checks option.

On-the-fly checks

When calling the param method, you may pass an array reference as the second parameter. This arrayref is passed straight through to the parameter's checks 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.



Randall Hansen <>

syntax highlighting: