CGI::POST_MAX use and control
Hi all,
I would appreciate some guidance in the use of CGI::POST_MAX. I've listed a
snippet of relevant code below from my program to illustrate.
When reading in data fields from an HTML form, I want to limit the size of
the data accepted from a TEXTAREA box. I don't want to depend upon my ISPs
timeouts and what-nots to stop a user from trying a DDOS on 'em.
The current incarnation of my script blows itself out of the water if the
$user_body variable (the TEXTAREA source) is greater than 4K, for example.
This is good.
I would like to be able to capture and control the process so that I don't
get rudely blown out of the water with a crude 500 Server message (this
would be gooder! g). I would like to: a)generate a useful message and, b)
set some flags, do some more processing, and send a message back to the user
to give them an opportunity to correct their input and atone for their sins.
(This would be more gooder! g)
I've read through the CGI.pm writeup, but I don't believe I'm applying it
correctly. I am having a problem understanding just how and where to make
use of CGI::POST_MAX, CGI::Carp, and probably cgi_error() in my code. Where
do I put 'em and can someone demonstrate with a similar snippet of code just
how and where these are used? For example, when this bombs with data 4096
bytes, I don't even see an error message in my error log file,
...cgi-log.txt -- that would be a nice diagnostic help, too.
If there is another prefered method to limit size of input, I would
appreciate learning about that, too!
Right now my code produces an 'accurate' result (a nuke will 'accurately'
kill a fly), but I would prefer to have it produce a 'precise' result
(perhaps a HOW-TO on using tightly focused gamma rays to zap that fly,
instead). It works, but its not elegant.
I'm looking for the state of most goodliness. g
(My apologies to non-native English readers of this list for my having fun
with the language, but its been a tough day...)
Thanks, all.
John--
[EMAIL PROTECTED]
===
#!/usr/bin/perl
use strict;
#use diagnostics;
use CGI qw/:standard/;
use CGI::Carp qw/fatalsToBrowser/;
BEGIN {
use CGI::Carp qw(carpout);
open(LOG, $ENV{DOCUMENT_ROOT}/data/cgi-log.txt) or
die(Unable to open $ENV{DOCUMENT_ROOT}/data/cgi-log.txt: $!\n);
carpout(LOG);
}
$CGI::POST_MAX = 1024 * 4; ## Max 4K post size
$CGI::DISABLE_UPLOADS = 1; ## Disable file uploads
$formin = new CGI;
$user_name = ' ';
$user_addr = ' ';
$user_to = ' ';
$user_subj = ' ';
$user_body = ' ';
$user_name = $formin-param('name');
$user_addr = $formin-param('from');
$user_to = $formin-param('to');
$user_subj = $formin-param('subject');
$user_body = $formin-param('body');
## If good form data
## process the form's input...and do good things...
## else
## create return HTML page and tell user where they've transgressed...
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI::POST_MAX use and control
Lisa,
Thanks!
I synthesized from your answer and realized that my use of 'use CGI::Carp
qw/fatalsToBrowser/;' was having me die long before I could have the code
handle the problem. I commented out the '...Carp...' block and, indeed, my
builtin code handled the error the way I'd intended.
I was even able to see my 'friendly' ;-) user's error message: Because your
message was too long, we ran out of electrons. Please shorten your e-mail
message.. When I shortened the message to less than the 4K I spec'd, the
form and code did the right thing and produced the intended e-mail.
Follow-up question: Does POST_MAX measure the length of the incoming stream
as the code asks for it -- $recd_data = $form-param('sent_data'); -- and
then pulls the plug if 'sent_data' goes outside the bounds of acceptable
social behavior?
I ask because, while this change worked in my current program, I want to
more fully understand the working principles for my next system.
Thanks.
John--
[EMAIL PROTECTED]
-Original Message-
From: Lisa Nyman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 23, 2001 1:20 PM
To: John
Cc: Beginners-CGI
Subject: Re: CGI::POST_MAX use and control
Hi,
On Thu, 23 Aug 2001, John wrote:
The current incarnation of my script blows itself out of the water if the
$user_body variable (the TEXTAREA source) is greater than 4K, for example.
This is good.
I would like to be able to capture and control the process so that I don't
get rudely blown out of the water with a crude 500 Server message (this
would be gooder! g). I would like to: a)generate a useful message and,
b)
set some flags, do some more processing, and send a message back to the
user
to give them an opportunity to correct their input and atone for their
sins.
(This would be more gooder! g)
In general, you always want to die gracefully from within a web script so
the error is logged and the user doesn't get an icky 500 error page.
For example, in database apps I write, for any error, I tell the user the
database is unavailable and I log the error.
The following has worked for me when dealing with POST_MAX:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 10;
$CGI::DISABLE_UPLOADS = 1;
$| = 1;
my $page = new CGI;
print $page-header;
$run = $page-param('RUN');
if (!$run cgi_error()) {
# do whatever you do for an error
dieWell (413: Max Posting surpassed.);
}
sub dieWell {
my $message = shift;
# remember to print proper headers if not done by now
print $thanks_for_playing_message\n;
# do logging of $message if you want, send yourself email, whatever
footer; # end my html -
exit;
}
Lisa Wolfisch Nyman [EMAIL PROTECTED] IT Warrior Princess
Life is too short to wear ugly underwear.
Get the facts at http://quickfacts.census.gov/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI::POST_MAX use and control
For myself I would prefer not to abort a script on this type of error...
A simple JavaScript to check for the max size of a textarea and an alert
is a much better way to handle this type of error, in my option... see
OnSubmit in some JavaScript reference and you should be able to find an
example like ..
O'Reilly's JavaScript The Definitive Guide, Chapter 16: Forms and Form
Elements, 16.5 Form Verification Example
Hope this give you some ideas...
jwm
-Original Message-
From: Lisa Nyman [mailto:[EMAIL PROTECTED]]
Sent: August 23, 2001 13:20
To: John
Cc: Beginners-CGI
Subject: Re: CGI::POST_MAX use and control
Hi,
On Thu, 23 Aug 2001, John wrote:
The current incarnation of my script blows itself out of the water if the
$user_body variable (the TEXTAREA source) is greater than 4K, for example.
This is good.
I would like to be able to capture and control the process so that I don't
get rudely blown out of the water with a crude 500 Server message (this
would be gooder! g). I would like to: a)generate a useful message and,
b)
set some flags, do some more processing, and send a message back to the
user
to give them an opportunity to correct their input and atone for their
sins.
(This would be more gooder! g)
In general, you always want to die gracefully from within a web script so
the error is logged and the user doesn't get an icky 500 error page.
For example, in database apps I write, for any error, I tell the user the
database is unavailable and I log the error.
The following has worked for me when dealing with POST_MAX:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 10;
$CGI::DISABLE_UPLOADS = 1;
$| = 1;
my $page = new CGI;
print $page-header;
$run = $page-param('RUN');
if (!$run cgi_error()) {
# do whatever you do for an error
dieWell (413: Max Posting surpassed.);
}
sub dieWell {
my $message = shift;
# remember to print proper headers if not done by now
print $thanks_for_playing_message\n;
# do logging of $message if you want, send yourself email, whatever
footer; # end my html -
exit;
}
Lisa Wolfisch Nyman [EMAIL PROTECTED] IT Warrior Princess
Life is too short to wear ugly underwear.
Get the facts at http://quickfacts.census.gov/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI::POST_MAX use and control
John,
Thanks for the idea.
I'd thought of using JavaScript, but I'm sunk if the user has Jscript turned
off on their PC and I felt I wanted a little more surety on this being
checked. I am going to re-visit the idea, however.
My current Perl code does catch the error and return a form to the user so
that they can reflect on their evil ways and correct their misdeeds. The
script won't abort on 'em. (I'm considering a file-based counter, so that
maybe the third time the same user flubs up I can really slap their paw,
however; but that's an enhancement g)
Thanks.
John--
[EMAIL PROTECTED]
-Original Message-
From: Moon, John [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 23, 2001 2:22 PM
To: John
Cc: Beginners-CGI
Subject: RE: CGI::POST_MAX use and control
For myself I would prefer not to abort a script on this type of error...
A simple JavaScript to check for the max size of a textarea and an alert
is a much better way to handle this type of error, in my option... see
OnSubmit in some JavaScript reference and you should be able to find an
example like ..
O'Reilly's JavaScript The Definitive Guide, Chapter 16: Forms and Form
Elements, 16.5 Form Verification Example
Hope this give you some ideas...
jwm
-Original Message-
From: Lisa Nyman [mailto:[EMAIL PROTECTED]]
Sent: August 23, 2001 13:20
To: John
Cc: Beginners-CGI
Subject: Re: CGI::POST_MAX use and control
Hi,
On Thu, 23 Aug 2001, John wrote:
The current incarnation of my script blows itself out of the water if the
$user_body variable (the TEXTAREA source) is greater than 4K, for example.
This is good.
I would like to be able to capture and control the process so that I don't
get rudely blown out of the water with a crude 500 Server message (this
would be gooder! g). I would like to: a)generate a useful message and,
b)
set some flags, do some more processing, and send a message back to the
user
to give them an opportunity to correct their input and atone for their
sins.
(This would be more gooder! g)
In general, you always want to die gracefully from within a web script so
the error is logged and the user doesn't get an icky 500 error page.
For example, in database apps I write, for any error, I tell the user the
database is unavailable and I log the error.
The following has worked for me when dealing with POST_MAX:
use CGI qw/:standard/;
$CGI::POST_MAX=1024 * 10;
$CGI::DISABLE_UPLOADS = 1;
$| = 1;
my $page = new CGI;
print $page-header;
$run = $page-param('RUN');
if (!$run cgi_error()) {
# do whatever you do for an error
dieWell (413: Max Posting surpassed.);
}
sub dieWell {
my $message = shift;
# remember to print proper headers if not done by now
print $thanks_for_playing_message\n;
# do logging of $message if you want, send yourself email, whatever
footer; # end my html -
exit;
}
Lisa Wolfisch Nyman [EMAIL PROTECTED] IT Warrior Princess
Life is too short to wear ugly underwear.
Get the facts at http://quickfacts.census.gov/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGI::POST_MAX use and control
I'd thought of using JavaScript, but I'm sunk if the user has Jscript turned off on their PC and I felt I wanted a little more surety on this being checked. I am going to re-visit the idea, however.never hurts to do both, never hurts to do both, your server will thank you for the less POSTs you're giving it! justin. s k a z a t - http://skazat.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: CGI::POST_MAX use and control
Justin, Whoops! Hadn't thought of that. Belt 'n suspenders is good. I'm sold. Besides, I'm am anthropomorphic enough to understand that my server has feelings, too. John-- [EMAIL PROTECTED] -Original Message- From: Justin Simoni [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 23, 2001 2:51 PM To: John Cc: Moon, John; Beginners-CGI Subject: Re: CGI::POST_MAX use and control I'd thought of using JavaScript, but I'm sunk if the user has Jscript turned off on their PC and I felt I wanted a little more surety on this being checked. I am going to re-visit the idea, however.never hurts to do both, never hurts to do both, your server will thank you for the less POSTs you're giving it! justin. s k a z a t - http://skazat.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
