Lots of useless code. Not clear where check_ip lives or the need for DBI or CGI. Basically all you need is:

package Apache2::Authclients;
  
use Apache2::RequestRec (); # for $r->content_type
use Apache2::Connection (); # for $c->remote_ip
use Apache2::SubRequest (); # for $r->internal_redirect
use Apache2::Const -compile => ':common';

sub handler {
    my $r = shift;
    my $c = $r->connection();
    if ( check_ip($c->remote_ip(), $r->dir_config('product')) ) {
        $r->internal_redirect($r->uri);
    }
    else {
        $r->internal_redirect('/path/to/login');
    }
}
[download]

Note that this code has a serious bug. You seem to assume that the remote_ip will be unique. If I am (say) at a university going through a proxy server (just about all connections will go through a proxy somewhere) the remote_ip for many connections will be the same. Thus if several people on campus were accessing your site simultaneously they would all have the same remote ip (you don't see their real ip which will be 10.x.x.x or 192.168.x.x or similar. The usual/common way to handle this is to assign a session cookie following a successful login. The logic then becomes if valid_session do stuff else login. A successful login give you a valid session key.

Session control and login is a common problem with multiple CPAN modular solutions. Have a look at Apache2::AuthCookie Apache2::AuthCookieDBI for example. No reason you can't roll your own session framework. No need to either as there are literally dozens of pre-rolled solutions, highly likely to work out of the box.

Hello,

Thank you to everyone who as reponsed very good pointers, Tachyon-II thank you for the advice, we authenicate through IP based,
so lets say a University has access to the website which we see as one IP but many users are viewing the site this is acceptable.
We will later add cookie's but we must first crawl before we can walk.

I also took note of your code you posted and again thank you.
How ever I'm still having the same issue, I have tried a number of differant
options based on your example and did some googling on some leads but nothing seems to work for me.

So to make it easilier I have added pretty much everything and converted to your example so your not guessing on what I'm trying to do.

package Apache2::Authclients;
use strict;
use DBI;
use CGI qw(:standard);
use Apache2::RequestRec (); # for $r->content_type
use Apache2::Connection (); # for $c->remote_ip
use Apache2::SubRequest (); # for $r->internal_redirect
use Apache2::Const -compile => ':common';


sub handler
{
my $r = shift;
my $c = $r->connection();


if ( check_ip($c->remote_ip(), $r->dir_config('product')) )
{
$r->internal_redirect($r->uri);
}
else {
$r->internal_redirect('/path/to/login');
}


sub check_ip
{
my ($ip, $product) = @_;
my $user;
my $conn = DBI->connect("DBI:Sybase:<NAME-DATABASE-SERVER>", "<USERNAME>", "<PASSWORD>") || die DBI->errstr;
$conn->do("<NAME-DATABASE>") || die DBI->errstr;
my $qry = "exec <STORED-PROCEDURE> '" . $ip . "','" . $product . "'";
my $smt = $conn->prepare($qry) || die DBI->errstr;
$smt->execute() || die DBI->errstr;
while(my $var = $smt->fetchrow_arrayref)
{
$user = $var->[0];
}


$smt = undef;
$conn->disconnect;
return $user;
}
}
1;

I have also included my apache Dir.

<VirtualHost *>
DocumentRoot /var/www/html/<product>
ServerName <product_DNS_Name>


<Directory "/var/www/html/<product>">
SetHandler modperl
PerlSetVar product <product>
PerlResponseHandler Apache2::Authclients


allow from all
Options +Indexes
</Directory>


ScriptAlias /cgi-bin/ /var/www/cgi-bin/
<Directory "/var/www/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Apache/2.0.55
mod_perl/2.0.2
Perl/v5.8.7


I'm not totally sure on if the apache Dir is correctly done so I have included this as well.


The DBI is used to make a connection to the database which checks for IP and product access, it returns a 0 or 1.
For the CGI I need because of the dir_config.

Again thank you all for taking the time to look at my issues.
this is the first time I have really asked issues like this on a forum and I must say I am impressed with everyones enthusiasm to help with quick response times.

cheers
overworked

Please do not roll this yourself. It is extremely broken. The whole reason mod_perl is fast is persistence. You have a non persistent DB connection which is just totally wrong. Connecting to a database is slow. In mod_perl you connect once, use lots (and handle unexpected disconnections). Compiling scripts is slow. In mod_perl you don't use anything in cgi-bin. You need proper session control. Saying you want to build it broken and fix it later is just plain stupid.

Lot's of people have spent lots of time on this task. Please use 1 of the many session control modules to do your sessioning properly. Please use one of the persistent database connection modules ie Apache2::DBI to handle this. Please use CPAN!!!!! Do it right the first time.

Have a read of this to get an idea of some basic design concepts. Have a look at this and this online mod_perl book and the sample chapter on authentication available free online out of The mod_perl Developer's cookbook

The return codes from apache handlers are not the same as HTTP codes. Some of them are for historical reasons, but it can't be counted on. HTTP codes are used in the headers and apache constants are used as handler return values.