Re: Apache2 Mod_perl 2 without a endless loop of redirect

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.

Comment on Re: Apache2 Mod_perl 2 without a endless loop of redirect Download Code

Replies are listed 'Best First'.
Re^2: Apache2 Mod_perl 2 without a endless loop of redirect by overworked (Novice) on Apr 25, 2008 at 18:11 UTC
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	[reply]
Re^3: Apache2 Mod_perl 2 without a endless loop of redirect by tachyon-II (Chaplain) on Apr 26, 2008 at 13:51 UTC
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	[reply]
Re^4: Apache2 Mod_perl 2 without a endless loop of redirect by overworked (Novice) on Apr 28, 2008 at 02:35 UTC
Hello Tachyon-II, I would like to thank you for taking the time in this matter. I will also take your advice about persistent and non-persistent matters. The session control is something I been pushing for a while, unfortunately I’m not a leading manager nor do my suggestions make it far since most of my suggestions are not marketable or doesn’t make the company money. I do what I’m told at best I try to squeak in things but making this area completely session based is something that will not be under the radar. I love doing things as best as they can base on the tech. and specs given (time allowed); I’m a firm believer of not redoing things because we always took the shortcuts to get it done. Well again I would like to thank you all for your assistance and time. Cheers, overworked	[reply]