cgi.pm distinguish between POST & GET

M

mike_solomon

I am using the CGI module and can get access to the POST & GET
variables

use CGI;
#create new cgi
my $m_cgi = new CGI;

#put cgi data into hash
my %m_cgi_data = $m_cgi->Vars;

What I would like todo is find some way of knowing whether a variable
is from a GET or a POST as for one form I would like to ignore GET's

Is this possible using cgi.pm?

Thanks
 
X

xhoster

yup read it before I posted

either I am not understanding it properly or it doesn't work for me

Well, that sucks. It does work for me, so I probably understand it
properly. If you showed us some code, maybe I could understand your
misunderstanding and correct it.

using url_param & param both returned a GET parameter

So then you know it is from the query string in the URL. Isn't that what
you wanted to know? Doesn't that solve your problem?

Xho
 
M

mike_solomon

yup read it before I posted

either I am not understanding it properly or it doesn't work for me

using url_param & param both returned a GET parameter

OK done some further tests

param returns both GET & POST

url_param returns GET

what I want is just POST but now I understand I can exclude anything in
url_param

Thanks for replying
 
K

Karlheinz Weindl

I am using the CGI module and can get access to the POST & GET
variables

use CGI;
#create new cgi
my $m_cgi = new CGI;

#put cgi data into hash
my %m_cgi_data = $m_cgi->Vars;

What I would like todo is find some way of knowing whether a variable
is from a GET or a POST as for one form I would like to ignore GET's

Is this possible using cgi.pm?

How about using request_method() to find out how your script was called?

Kh
 
X

xhoster

OK done some further tests

param returns both GET & POST

Ah, now I see the problem.
No, param returns either GET or POST--but not both--for any one form
submission.
url_param returns GET

If the form was submitted with GET, both param and url_param return the
parameters from the URL.

If the form was submitted with POST but also had URL parameters thrown in
too, then param returns only the POSTed parameteters and url_param returns
only the URL ones.

what I want is just POST but now I understand I can exclude anything in
url_param


If the form was submitted with POST, then the exclusion has already
been done for you in param(), and you don't need to use url_param. If the
form was submitted with GET, then you could just throw up a "drop dead,
hacker" page and never even look at param.

Xho
 
U

Uri Guttman

x> Ah, now I see the problem.
x> No, param returns either GET or POST--but not both--for any one form
x> submission.

cgi.pm supports having both get (in the url) and post params on the same
cgi call. it will mix the params from both sources. i am not sure which
will override the other (if that happens). from cgi.pm:

$query = new CGI;

This will parse the input (from both POST and GET methods)
and store it into a perl5 object called $query.

note the 'both' in there.

uri
 
U

Uri Guttman

x> Ah, now I see the problem.
x> No, param returns either GET or POST--but not both--for any one form
x> submission.
x> Do you have example code to demonstrate that?
^^^^^^^^^^^^^^^

x> I note the 'both', but I do not the 'in one form submission'. Quite the
x> opposite:

also note the underlined parts above.

x> MIXING POST AND URL PARAMETERS
x> ...
x> It is possible for a script to receive CGI parameters in the URL as
x> well as in the fill-out form by creating a form that POSTs to a URL
x> containing a query string (a "?" mark followed by arguments). The
x> param() method will always return the contents of the POSTed
x> fill-out form, ignoring the URL's query string.

i never said anything about access params from both get/post. i just was
pointing out that you can use both and cgi.pm will handle it. dealing
with both in a submission is up to you but you can get both sets of
params if desired.

<snip of cgi script i won't run>

uri
 
M

mike_solomon

OK done some further tests

param returns both GET & POST

url_param returns GET

what I want is just POST but now I understand I can exclude anything in
url_param

Thanks for replying


I have added the following code to remove any GET - seems to do what I
want :)

#create new cgi
$m_cgi = new CGI;

#put cgi data into hash
%m_cgi_data = $m_cgi->Vars;

#remove GET from hash
for my $key (keys %m_cgi_data ) {
delete $m_cgi_data{$key} if $m_cgi->url_param($key);
}
 
S

Samwyse

I am using the CGI module and can get access to the POST & GET
variables

use CGI;
#create new cgi
my $m_cgi = new CGI;

#put cgi data into hash
my %m_cgi_data = $m_cgi->Vars;

What I would like todo is find some way of knowing whether a variable
is from a GET or a POST as for one form I would like to ignore GET's

Is this possible using cgi.pm?

I suspect that what you really want to know is whether a given request
is the result of a GET or a POST. A variable doesn't come from a GET or
a POST, it comes from a URL or a form. It is perfectly valid (although
little used) to do this in a form:
<form method="POST" action="test.cgi?this=hello">
<input type="hidden" name="that" value="world">
</form>
In the above, two variables are submitted, one via the URL and the other
via the form. param() returns both, url_param only returns the first.
Of course, a quesy submitted by someone typing in an URL can only
contain URL parameters. If you want to catch that, then you need to
check request_method(), which will contain either 'GET' or 'POST'.

OTOH, a person can copy an entire form into a local .HTML file and
change all of the input fields to 'hidden' with default values. A bit
of Javascript can even launch the request as soon as the file is opened,
allowing someone to send a query without passing through your website.
The only way to (mostly) prevent that is to examine the HTTP-Referrer
header to see where a request originated (but there are ways to spoof
that as well).
 
G

Gunnar Hjalmarsson

I have added the following code to remove any GET - seems to do what I
want :)

#put cgi data into hash
%m_cgi_data = $m_cgi->Vars;

#remove GET from hash
for my $key (keys %m_cgi_data ) {
delete $m_cgi_data{$key} if $m_cgi->url_param($key);
}

Does the result of that differ from:

%m_cgi_data = $m_cgi->Vars if $ENV{REQUEST_METHOD} eq 'POST';
 
X

xhoster

Samwyse said:
I suspect that what you really want to know is whether a given request
is the result of a GET or a POST. A variable doesn't come from a GET or
a POST, it comes from a URL or a form. It is perfectly valid (although
little used) to do this in a form:
<form method="POST" action="test.cgi?this=hello">
<input type="hidden" name="that" value="world">
</form>
In the above, two variables are submitted, one via the URL and the other
via the form. param() returns both,

No, it does not. Have you tested this?

Xho
 
R

Randal L. Schwartz

mike> What I would like todo is find some way of knowing whether a variable
mike> is from a GET or a POST as for one form I would like to ignore GET's

I would prefer that you not go out of your way to ignore "GET". What
goal are you trying to achieve with this design?

print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
 
M

mike_solomon

Randal said:
mike> What I would like todo is find some way of knowing whether a variable
mike> is from a GET or a POST as for one form I would like to ignore GET's

I would prefer that you not go out of your way to ignore "GET". What
goal are you trying to achieve with this design?

print "Just another Perl hacker,"; # the original

Basically I was playing with a password system

It didn't need to be too secure but if the password came through as a
GET rather than a POST then it was invalid

In the screens there should never be a GET so I thought deleting them
was the simplest way
 
R

Randal L. Schwartz

mike> Basically I was playing with a password system

mike> It didn't need to be too secure but if the password came through as a
mike> GET rather than a POST then it was invalid

mike> In the screens there should never be a GET so I thought deleting them
mike> was the simplest way

Both GET and POST can be sniffed, so you're not really helping security there.
The main difference between GET and POST is that the params in a GET
are also logged, which shouldn't be made public anyway.

Again, not sure of the problem you're solving, because it doesn't really
solve anything to change the method.

print "Just another Perl hacker,"; # the original

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
 
S

Scott Bryce

Basically I was playing with a password system

It didn't need to be too secure but if the password came through as a
GET rather than a POST then it was invalid

You have got to be kidding! How about if the password is wrong, then it
is invalid. Don't worry about how the password was passed in.
 
M

mike_solomon

Randal said:
mike> Basically I was playing with a password system

mike> It didn't need to be too secure but if the password came through as a
mike> GET rather than a POST then it was invalid

mike> In the screens there should never be a GET so I thought deleting them
mike> was the simplest way

Both GET and POST can be sniffed, so you're not really helping security there.
The main difference between GET and POST is that the params in a GET
are also logged, which shouldn't be made public anyway.

Again, not sure of the problem you're solving, because it doesn't really
solve anything to change the method.

print "Just another Perl hacker,"; # the original

Oh well it seemed like a good idea at the time and I've learnt a bit :)

Gone back to plan A where I accept POST's & GET's and do a database
lookup for usernames and passwords

Thanks for the help everyone
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,043
Latest member
CannalabsCBDReview

Latest Threads

Top