Without using GET parameters, you only have a couple different possibilities.

Big Kludge (not recommended) - Use LWP to submit the query and get the HTML, then display to the client. The query doesn't come from the browser so hokey stuff is going to happen.

Cookies - Store the information in cookies and then redirect.

Sessions - Give each user a unique session ID every time they login and pass that with GET. Store the information that needs to be submitted in a flat file or database.

The reason for all this is because POST works by sending the input through STDIN. That means you can't cleanly recreate it on the server side because the client must be involved to properly use POST.

I may be missing the boat on this one, but how are you submitting input to your cgi?

As a matter of philosophy, if you have the option, always use POST instead of GET. I believe POST doesn't show parameters in the 'Address' bar or the logs (not good if you are submitting passwords as parameters).

On a side note, if this is a public server, you may want to change the name to 'entrance.cgi' or something similar. We have had plenty of instances where a script kiddie scans our servers for anything beginning with login (login.cgi, login.pl, login.cfm). This is a precursor to attack, and can be a possible headache. You should take the temptation away and rename it something benign.

if you have any other questions, /msg me and we can talk about it.

J. J. Horner

Linux, Perl, Apache, Stronghold, Unix

jhorner@knoxlug.org http://www.knoxlug.org

But you can't redirect to a POST (that I'm aware of), which was the original poster's desire (I understand).

 
use Crypt::IDEA;              
my $key = pack("H32", "0123456789ABCDEF0123456789ABCDEF");
my $cipher = new IDEA $key;
my $ciphertext = $cipher->encrypt(query_string());
[download]

Not a real elegant solution, but it may work for what you want to do.

 
<input type="hidden" name="foo" value="210">
<input type="hidden" name="bar" value="whatever">
<input type="hidden" name="baz" value="BIB1">
[download]

Depends on much you want to "hack-proof" the system. Using hidden variables is sufficient for safe parameter passing, but anything that involves authentication or data that can affect the security of the system is unsafe. Far too easy to modify the page and resubmit.

I'm not completely sure of this, but I think that putting hidden variables in has the effect of tempting people who might not otherwise be interested in hacking your system.

In a site I maintain at work, I only pass a session ID in hidden variables. Each time the page is submitted, the session ID is checked in a mySQL database, and the users permissions are checked for the operation they are trying to perform. One interesting (but rarely used) side effect is that I can change a users permissions on the fly (i.e. while s/he's still logged in), and permit or yank privledges (typically, I start users with a minimum of permissions, and require them to justify any additional privledges they need).

I think you might have a point about the hidden variables encouraging hackers. I suspect the word "hidden" triggers the curious.
Of course you can always check the referrer, but I accept that is not foolproof.
The hidden session id is a neat idea. Sure, it does'nt stop the occasional attempt to snarf someone else's id, but the amount of effort required outweights the simple pleasure of a vicarious hacking attempt, unlike just editing a url query-string, which can be done on the spur of the moment.

The cgi file may look like this:

#!/usr/bin/perl -w

use MYModule;

(MyModule::doPage(),      exit) if defined CGI::param('doPage');
(MyModule::doOtherPage(), exit) if defined CGI::param('doOtherPage');
[download]

Russ