NAME
Bio::Das::ProServer::Authenticator::ip - authenticates DAS requests by IP address
VERSION
$LastChangedRevision: 688 $
SYNOPSIS
To authenticate a request:
my $auth = Bio::Das::ProServer::Authenticator::ip->new({
'config' => {
'authallow' => $, # IP whitelist
},
});
my $allow = $auth->authenticate({
'peer_addr' => $, # packed
'request' => $, # HTTP::Request object
...
});
Once authenticated the IP address is stored:
if ($allow) {
my $ip = $auth->ip();
}
To simply perform IP address authentication but not deny requests, configure the source with a lax IP range (e.g. "0/0"). This allows the source to alter its behaviour in a more subtle fashion (e.g provide different data for different sites).
DESCRIPTION
Authenticates requests according to a 'whitelist' of IP address ranges. Requests from clients not within one of these ranges are denied.
The IP addresses that are checked against the whitelist are: 1) that of the socket connection 2) those listed in the X-Forwarded-For HTTP header
The latter is necessary for clients and servers operating behind proxies.
IMPORTANT NOTE: Because IP addresses can be spoofed by clients, this is NOT a robust method of securing data.
CONFIGURATION AND ENVIRONMENT
The whitelist for IP addresses is configured in the source INI section, using any combination of specific, additive, range or CIDR format IPs. Valid separators are comma and semicolon.
[mysource]
authenticator = ip
authallow = 1.2.3.4,193.62.196.0 + 255 , 123.123.123.1 - 123.123.123.10 ; 192.168/16
SUBROUTINES/METHODS
authenticate : Applies authentication to a request.
Requires: a hash reference containing details of the DAS request
Returns: either nothing (allow) or a HTTP::Response (deny)
my $allow = $oAuth->authenticate({
'peer_addr' => $, # packed (socket IP address)
'request' => $, # HTTP::Request object (for X-Forwarded-For header)
...
});
ip : Gets the authenticated IP address
my $sIp = $oAuth->ip();
init : Initialises the IP whitelist
DIAGNOSTICS
my $auth = Bio::Das::ProServer::Authenticator::ip->new({
...
'debug' => 1,
});
DEPENDENCIES
BUGS AND LIMITATIONS
Clients that are separated from the server by an anonymising HTTP proxy (i.e. one that does not reveal the client's IP address in the X-Forwarded-For HTTP header) will always fail this method of authentication.
Note that clients may spoof an IP address in the X-Forwarded-For header. Therefore this method of authentication is not a robust security precaution.
INCOMPATIBILITIES
None reported.
AUTHOR
Andy Jenkinson <andy.jenkinson@ebi.ac.uk>
LICENSE AND COPYRIGHT
Copyright (c) 2008 EMBL-EBI