Nice question, Ryszard.

I would subclass CGI::Application and reimplement the query method:

sub query {
  my $self = shift;
  my ($query) = @_;

  # We're only allowed to set a new query object if one does not yet e
+xist!
  unless (exists($self->{__QUERY_OBJ})) {
    my $new_query_obj;

    # If data is provided, set it!  Otherwise, create a new one.
    if (defined($query) && $query->isa('CGI')) {
      $new_query_obj = $query;
    } else {
      $CGI::POST_MAX=1024 * 100;  # max 100K posts
      $new_query_obj = CGI->new();
    }

    $self->{__QUERY_OBJ} = $new_query_obj;
  }

  return $self->{__QUERY_OBJ};
}
[download]

Beware, the code isn't tested. The new method could also use a parameter passed during start up:

my $webapp = App->new(
               TMPL_PATH => 'App/',
               PARAMS => {
                          'max_upload_size' => 100
               }
             );
[download]

Then you could check this parameter and act accordingly inside your reimplemented method. Another solution could be creating a new CGI object (with POST_MAX set properly) and passing it to application init; C::A will recognize the object and use it; here is an excerpt from the man page:

QUERY - This optional parameter allows you to specify an already-created CGI.pm query object. Under normal use, CGI::Application will instantiate its own CGI.pm query object. Under certain conditions, it might be useful to be able to use one which has already been created.

Hope this helps. Ciao, Valerio

That's not really a good way to do it. What happens when a new version of CGI::Application comes out that makes a change in query()? The code above will break. Instead, call the real query() to do the work using SUPER:

package CGI::Application::POST_MAX;
use base 'CGI::Application';

sub query {
  my $self = shift;
  if (not exists $self->{__POST_MAX_SET__}) {
    $CGI::POST_MAX=1024 * 100;  # max 100K posts
    $self->{__POST_MAX_SET__} = 1;
  }
  return $self->SUPER::query(@_);
}

1;
[download]

Of course, this still isn't 100% future-proof since it will break if a future version of CGI::Application uses the hash key "__POST_MAX_SET__" but I'd consider that an acceptable risk.

But is this even necessary? Can't you just put this at the top of your CGI::Application class:

BEGIN { $CGI::POST_MAX = 1020 * 100; }

-sam

For instance, members using your CGI application may have a larger upload limit than non-members, so creating a separate directory with a "members-only" configuration allows you to do that with minimal effort.

--
hiseldl
"Act better than you feel"

I would recommend only allowing authenticated users to do uploading. Your first level of protection should be authentication. I would then recommend limiting the size of each upload and the total size per application or user. If you are using Apache servers, you can set some limits at the server level Apache Limits . But this limit is only for each individual file. Your Perl code can also limit the file size. In this example, the author creates temporary directories on the fly so that someone cannot guess the directory name and some how force an upload. I have seen this technique used a lot so I would recommend it if you are concerned about DoS attacks. Quick and Dirty Method . Here is another example, which uses a text file that could be the starting point for tracking the total size uploaded by application or user. User Tracking .

On the Perl side of the uploading CGI, I would log all requests for uploading, including the IP address, authenticated name, file name, file size, and a success code. This audit trail is most useful for finding problems and detecting attacks.

In closing, I would hope that you would not rely on a single point of failure to protect your uploads. A good blend of Operating System, Server, and Perl limits should give you a good three-layer umbrella.

Richard

There are three types of people in this world, those that can count and those that cannot. Anon