The quick-n-dirty answer would be to read up on apache .htaccess files.

The better answer is to read up on Cookies and the PerlAccessHandler directive in Apache. When Apache processes a URL request, that request goes through several phases, one of which is ("Is this user allowed to view this URL?"). By writing your own PerlAccessHandler, you can protect your site against users who aren't logged in.

A quick example (I'll try to minimize the errors :)

package MyAccessHandler;

use strict;
use warnings;

use Apache::Request;
use Apache::Cookie;
use Apache;

sub handler {

  my $r = shift;

  my $url = $r->hostname . $r->uri();
  my $file_path =  $r->parsed_uri()->unparse();

  # do not protect login page.
  return Apache::OK if $file_path=~ /login\.html$/;

  my $can_access = 0;

  ## If the user has a cookie, see if user has access.
  my $cookie = eval{
     ({Apache::Cookie->new($r)->parse()}->{cookie}->value) 
  };

  if ($cookie) {
     $can_access = MyValidationRoutine($cookie);
  }

  # return OK if they're allowed     
  return Apache::OK if ($can_access);

  # otherwise, redirect
  $r->internal_redirect('/login.html');
  return Apache::Constants::DONE();

}
[download]

Things to read up on: Apache::Request, Apache::Cookie. O'Reilly's "Apache Modules with C and Perl" is a good resource as well, though it's a little out of date and written for Apache 1.3.x, not 2.0.x. Is there a good Apache 2.0.x book out there?

Side note - this was written for Apache 1.3.x - I know things have changed in 2.0.x, but the same general idea applies.

If you have some reason against using cookies, you can have all of your cgi scripts (except the base) check the referrer URL and bounce them back to the login cgi if the referrer isn't your site. Of course, any decent hacker can get around this too, but it would work in the case of someone just bookmarking a lower cgi.

- - arden.

i have to concur w/the other two posters - if they're in a 'secure' area of your site - ya gotta go w/cookies.

some other thoughts re: cgi-security -

1) cgi-bin shouldn't be in your document-root (this'll deter ppl browsing to it, like you said were happening)

2) change your request method in your script and form to POST. Get requests come appended to a query_string and in basically plain text (anyone lookin' over your visitor's shoulder could read their password in the link) - whereas POST requests come url-encoded via standard-input (STDIN). Also - POST requests aren't cached - which'll deter someone from using the back-button to access those files again. (If someone new were to hop onto the pc.)

i'd also consider lookin' into some encryption (ssl, pgp or even crypt() w/generating or comparing passwords), if the visitor's info is sensitive (financial-related, etc). Ya don't want anyone stealing your customers' info - bad business

Just some thoughts ;-)

ps: ty swngnmonk - i actually needed a couple of those docs ya posted :-)

Just a quick comment about sessions - you don't have to use cookies to use sessions. You can pass the session key around in the URL, or in a hidden variable (as long as the user only navigates via form submit buttons). As long as your session key is reasonably random, people won't be able to just hit the CGI with a made-up, but valid, key. Then, the CGI that requires a valid login can check the session file (kept on the server) and see if it exists, and corresponds to a logged in user.