in reply to Discriminating between local and remote IP's

I have a local intranet that will not require an extensive logon, but if you are accessing it via the internet, it will require a more though logon proceder as per my bosses request.

This isn't really answering your question, but I can't help wondering if Perl is the right place to be solving this problem. When you talk of an intranet, I assume you are talking about a web server. If you are talking about a web server, chances are good you're talking about Apache.

In this case, you just want to set your server up so that it's unauthenticated for local addresses, but authenticated for everyone else. Other web servers offer similar functionality

<Location /foo> Order deny,allow Satisfy any AuthType Basic AuthName $realm AuthGroupFile /usr/local/www/auth/groups AuthUserFile /usr/local/www/auth/users Allow from 192.168.0.0/24 Require valid-user # or whatever, e.g. require group foo Deny from all </Location>

Apache plug-ins exist to let you authenticate against an LDAP server, or a database or other such repositories.

In other words, let Apache worry about authentication, because it's good at doing that; this will simplify your Perl code.

- another intruder with the mooring of the heat of the Perl

Replies are listed 'Best First'.
Re^2: Discriminating between local and remote IP's (Apache ACLs)
by mbeast (Beadle) on Oct 04, 2004 at 21:36 UTC
    I was wondering if you could do in through Apache by <Listen>ing on both the external and internal IP then set up a virtual host for each ip address. Add Apache auth to the external host.
    Listen xxx.xxx.xxx.xxx:80 Listen 192.168.xxx.xxx:80 <VirtualHost xxx.xxx.xxx.xxx:80> <Location /> AuthType Basic ... </Location> </VirtualHost> <VirtualHost 192.168.xxx.xxx:80> <Location /> #AuthType Basic ... </Location> </VirtualHost>
    (untested and refers to Apache 2.0)
      Using virtual hosts to bypass authentication is not really a good idea as it solely relies on the assumption that someone outside won't know the internal vhost name. And as (AFAIK) this only needs to be send in the HTTP header it would make it very easy to manipulate (an attacker would only have to change his hosts file).
      Update: Silly me, above example isn't about name-based vhosts...