Database Authentication
HI all ! I want to make a Database Authentication for my site. I have a PostgreSQL Database. I made a connect_on_init by user 'web_user' to the database. The question is: where better to make site users ? Create them as database users and put into system pg_shadow and pg_group tables or create new table, for example 'web_user' and work with it ? Best regards, Vladimir
Re: [OT] Database Authentication
Not exactly a mod_perl question but I'm sure it's something we've all thought about before... Vladimir S. Tikhonjuk wrote: I want to make a Database Authentication for my site. I have a PostgreSQL Database. I made a connect_on_init by user 'web_user' to the database. The question is: where better to make site users ? Create them as database users and put into system pg_shadow and pg_group tables or create new table, for example 'web_user' and work with it ? Think about the scope of the application - how many users? is it open to the public? A lot of the time, you should create your own table of users - the user has a relationship with the app, the app has a relationship with the DB. http://thedailywtf.com/forums/thread/79206.aspx cheers John
Authentication
Hi all! I'm thinking about 2 methods of authentication users for my site. May be you'll help me to choose one of them, or advice me something else. The first method: using PerlAuthenHandler on '/' Location. The second method: simple handler, for example http://localhost/login, which checks login and password, If everything is O.K. make session, send cookie with session id. And another handler which checks every reqest for Cookie with session id and desided whether to give access or not. Disadvantage (as I think) of first method: before every request make SQL query to the database for varification login and password. Best regards, Vladimir
Re: Authentication
On 8/3/06 7:51 AM, "Vladimir S. Tikhonjuk" <[EMAIL PROTECTED]> wrote: > Hi all! > > I'm thinking about 2 methods of authentication users for my site. > May be you'll help me to choose one of them, or advice me something else. > > The first method: using PerlAuthenHandler on '/' Location. > > The second method: simple handler, for example > http://localhost/login, which checks login and password, If everything > is O.K. make session, send cookie with session id. And another handler > which checks every reqest for Cookie with session id and desided whether > to give access or not. > > Disadvantage (as I think) of first method: before every request make > SQL query to the database for varification login and password. You can do both. See things like: http://search.cpan.org/~mschout/Apache-AuthCookie-3.10/lib/Apache/AuthCookie .pm Sean
PerlResponseHandler ignored
Hello,
I've tried to use one of the examples found in the mod_perl docs, but the
PerlResponseHandler is not taken into consideration.
My Perl module is:
---
package Testing::Response;
use strict;
use Apache2::RequestRec (); # for $r->content_type
use Apache2::RequestIO (); # for $r->print
use Apache2::Const -compile => ':common';
sub handler {
my $r = shift;
$r->content_type('text/plain');
$r->subprocess_env;
for (sort keys %ENV){
$r->print("$_ => $ENV{$_}\n");
}
return Apache2::Const::OK;
}
1;
-
With the httpd config:
-
Order deny,allow
allow from all
SetHandler perl-script
PerlResponseHandler Testing::Response
-
Still, my Apache sends it's content as the filter doesn't even exists.
What am I missing here?
Thank you,
Cristi
--
Cristi Barladeanu
Developer
GRAPEFRUIT
tel/fax: +40 232 233066, 233068
mobile: +40 724 363640
www.grapefruit.ro
Re: PerlSetVar
Well, now I'll try to explain why I have asked such question. I
have
startup.pl with connect_on_init dunction.
Also, I want to use Apache::AuthDBI. And I want options for
Apache::DBI->connect(...) to be stored into httpd.conf
or another but the only place.
I think that I could declare vars into httpd.conf and then use
it in
startup.pl and Apache::AuthDBI.
Storing connection options such as login and password into
environment vars - not very good idea, I thik :)
Personally, I use ENV to set 'production#', 'dev#' id for the machines
the SQL passwords are hardcoded into the app, along with other
traditionally environment variables , in a perl config and are
accessed via something like this:
$server{ $EVN{server_id} }{ $varname }
while there are some disadvantages to this...
i have 1 line in my httpd.conf that includes a httpd.conf for my
modperl app, which I keep in svn along with the app
i only set 1 var in httpd.conf, and don't use that powerful (yet
bastardized integration of 2 things) mod_perl interface to httpd.conf
- its all in the app
and everything is in svn. in a single directory. clustering is as
easy as 'svn co' , oooh!
Re: PerlSetVar
On Thu, 2006-08-03 at 08:47 +0300, Vladimir S. Tikhonjuk wrote: > Well, now I'll try to explain why I have asked such question. I have > startup.pl with connect_on_init dunction. > Also, I want to use Apache::AuthDBI. And I want options for > Apache::DBI->connect(...) to be stored into httpd.conf > or another but the only place. In httpd.conf: %MyConfig::DBI_CONNECTION_OPTIONS = (password => 'blah', etc.); Then just access that variable where you need it. - Perrin
Re: Authentication
Vladimir S. Tikhonjuk <[EMAIL PROTECTED]> [03-08-2006 13:51]: > The second method: simple handler, for example > http://localhost/login, which checks login and password, If everything > is O.K. make session, send cookie with session id. And another handler > which checks every reqest for Cookie with session id and desided whether > to give access or not. > Disadvantage (as I think) of first method: before every request make > SQL query to the database for varification login and password. You have to do a query to check if the session is valid anyway. Valid: exists, hasn't expired, client's IP matches (ID might have been stolen somehow), etc. With persistent database connections and prepared statements it doesn't hurt that much in terms of performance. Just make sure you're not checking what you don't have to (images, *.css, etc). -- Radosław Zieliński <[EMAIL PROTECTED]> pgpLOzrRB12Mi.pgp Description: PGP signature
Re: Authentication
Radoslaw Zielinski wrote:
> With persistent database connections and prepared statements it doesn't
> hurt that much in terms of performance. Just make sure you're not
> checking what you don't have to (images, *.css, etc).
>
Which is why (we) generally suggest that you don't setup handlers on Location /. It generally is more trouble then its
worth, but is useful from time-to-time.
See the 2 attachments for an example.
--
Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."
Listen 80
NameVirtualHost *
ServerName X
RewriteEngine On
#RewriteLogLevel 2
#RewriteLog /base/logs/httpd-rewrite_log
RewriteRule ^/path/login https://%{SERVER_NAME}/path/login [L,R]
DocumentRoot/base/htdocs
Alias /images/"/base/images/"
Alias /css/ "/base/css/"
Alias /js/"/base/js/"
ErrorLog "/base/logs/httpd-error_log"
CustomLog "/base/logs/httpd-access_log" common
CustomLog "/base/logs/httpd-referer_log" referer
CustomLog "/base/logs/httpd-agent_log" agent
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
PerlMapToStorageHandler NS::MapToStorage
### AAA
AuthType Basic
AuthName "TEXT"
Require valid-user
PerlAccessHandler NS::Access
PerlAuthenHandler NS::Authen
PerlAuthzHandler NS::Authz
## Registered
SetHandler modperl
PerlResponseHandler NS::Login
## Not protected
SetHandler modperl
PerlResponseHandler NS::Privacy
SetHandler modperl
PerlResponseHandler NS::Register
## Loggged in - ALL
SetHandler modperl
PerlResponseHandler NS::Logout
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl.crl
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLMutex file:/base/logs/httpd-ssl_mutex
SSLSessionCache shm:/base/logs/httpd-ssl_gcache_data(512000)
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
Listen 443
NameVirtualHost *
ServerName X
SSLEngine On
SSLCertificateFile /base/conf/certs/X.crt
SSLCertificateKeyFile /base/conf/keys/X.key
RewriteEngine On
#RewriteLogLevel 2
#RewriteLog /base/logs/httpsd-rewrite_log
RewriteRule ^/path/intro http://%{SERVER_NAME}/path/intro [L,R]
ErrorLog "/base/logs/httpsd-error_log"
CustomLog "/base/logs/httpsd-access_log" common
CustomLog "/base/logs/httpsd-referer_log" referer
CustomLog "/base/logs/httpsd-agent_log" agent
DocumentRoot/base/htdocs
Alias /images/"/base/images/"
Alias /css/ "/base/css/"
Alias /js/"/base/js/"
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
PerlMapToStorageHandler NS::MapToStorage
## Registered
SetHandler modperl
AuthType Basic
AuthName "TEXT"
Require valid-user
PerlAccessHandler NS::Access
PerlAuthenHandler NS::Authen
PerlResponseHandler NS::Login
Re: Authentication
On Aug 3, 2006, at 12:31 PM, Radoslaw Zielinski wrote: Valid: exists, hasn't expired, client's IP matches (ID might have been stolen somehow), etc. I find IP matching to be utterly useless. IPs for dialup/broadband users change like crazy as their ISPs funnel stuff into/out of proxies. my own ip can change every 3 minutes at times. its annoying.
chown executed by the apache user
Basel, Donnerstag, 3. August 2006, 07:51:47 . *chown executed by the apache user* Hello Mod_Perl List I need to change the uid, 'chown' for a file via the apache-perl process. People can work via FTP/WebDAV on files, but also via a Web Interface. For the web I have basic authentication, and of course when touching a file, it has the uid of the Apache process. As I use the FS to keep owner information, that's not what I want! Afaik I can only 'chown' while being root. An to become root (what I wouldn't like, but would do if it would solve the problem) again I would need to be root. An of course I will never let the Apache running as root. How would you solve that problem? mod_perl 1.0, Apache 1.x . Best Regards, Christian - [EMAIL PROTECTED] -
Re: chown executed by the apache user
Write a daemon running as root that watches a db for files that need to be chowned and periodically runs the chown. Have your web app update the db which the daemon than watches. Make sure it can only chown files in certain directories. Fancy step 2 will be a wakeup message your web app sends to the daemon to run and report status. Regards, KAM *chown executed by the apache user* I need to change the uid, 'chown' for a file via the apache-perl process.
X-Forwarded-For
my mp2 needs to get the ip of the remote address on some installations, mp2 is on port 80 on other installations, mp2 is on 80xx and the ip is in X-Forwarded-For i'd like to ensure that i pull the ip off the right place, under the right conditions. all of my get_ip() calls happen in a shared library though, so I need to figure out a way to handle this under those constraints, and not deal with spoofs. first i found this module Apache::ForwardedFor http://search.cpan.org/~jlawrenc/Apache-ForwardedFor-0.5/lib/Apache/ ForwardedFor.pm but its Apache1 not porting nicely designed oddly- doesn't seem to forw short of rewriting it , which i might have to do, maybe someone has an apach2 compatible solution already? i'm thinking that the easiest way to do this would be: httpd.conf- run a preliminary handler that strips all x-forwarded-for headers unless: we're running on port 80 we're running on port 80 but there's some internal lan header marking that says its coming off a load balancer i control although i could just do a conditional rewrite of headers in a new forwarded module
Re: X-Forwarded-For
Jonathan Vanasco wrote:
my mp2 needs to get the ip of the remote address
on some installations, mp2 is on port 80
on other installations, mp2 is on 80xx and the ip is in X-Forwarded-For
You could re-write the remote IP at an early stage - add a
PerlFixupHandler or PerlTransHandler which goes something like (assuming
its IPv4!):
sub handler { my $r=shift;
if($r->headers_in->{'X-Forwarded-For'} =~/(\d+\.\d+\.\d+\.\d+)/){
$r->remote_ip($1);
}
return DECLINED; # let other handlers run too
}
Remember your proxy might be just be adding to an existing
x-forwarded-for header if the user already came from a proxy, so adjust
the regex to pick the right IP - it's probably the first one in a comma
separated list if all the proxies are well behaved but remember it's a
non-standard header.
John
Re: X-Forwarded-For
On Fri, 4 Aug 2006, John ORourke wrote:
Jonathan Vanasco wrote:
my mp2 needs to get the ip of the remote address
on some installations, mp2 is on port 80
on other installations, mp2 is on 80xx and the ip is in X-Forwarded-For
You could re-write the remote IP at an early stage - add a PerlFixupHandler
or PerlTransHandler which goes something like (assuming its IPv4!):
sub handler { my $r=shift;
if($r->headers_in->{'X-Forwarded-For'} =~/(\d+\.\d+\.\d+\.\d+)/){
$r->remote_ip($1);
}
return DECLINED; # let other handlers run too
}
Remember your proxy might be just be adding to an existing x-forwarded-for
header if the user already came from a proxy, so adjust the regex to pick the
right IP - it's probably the first one in a comma separated list if all the
proxies are well behaved but remember it's a non-standard header.
Here's a snippet of code that I've used to do that:
my $ReIpNum = qr{([01]?\d\d?|2[0-4]\d|25[0-5])};
my $ReIpAddr =
qr{^$ReIpNum\.$ReIpNum\.$ReIpNum\.$ReIpNum$};
my $host = $r->headers_in->get('X-Forwarded-For') ||
$r->connection->remote_ip;
if ($host =~ /,/) {
my @a = split /\s*,\s*/, $host;
for my $i (0 .. $#a) {
if ($a[$i] =~ /$ReIpAddr/
and $a[$i] ne '127.0.0.1') {
$host = $a[$i];
last;
}
}
$host = '127.0.0.1' if $host =~ /,/;
}
Note that in Apache/2 X-Forwarded-For is added within
mod_proxy_http:
http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
which thus must be enabled.
--
best regards,
Randy Kobes
Re: X-Forwarded-For
thanks for the info. i just said screwit and i wrote a new module.
Apache2::xForwardedFornication
or
Apache2::xForwardedFor
i took Apache::ForwardedFor , tried to port it, disliked a lot of
things, and decided this would be a good chance to just rewrite it
entirely and add some new hooks
i think about 5 lines are the same :)
the big improvements ( i think ) are this:
a- specify the x-forwarded-for header name
b- specify a required additional header + value ( say you want to
embed x-forwarded-by='modperllist' on your gateway , to make sure its
an internal item )
c- returns forbidden on failed items
d- ignores favicon
e- you can set the forwardedfor to be required or not ( in case you
want to access the same server directly instead of through a proxy )
and, of course, all of that is configured in httpd.conf
i'm sure i made some mistakes though.
would people be so kind as to look it up and give me some feedback?
and should i contribute this to cpan or directly to mod_perl ?
package Apache2::xForwardedFor;
use strict;
use constant DEBUG=> 0;
use constant TEST=> 0; # note that there are 2 testing levels TEST>1 will set the required additional header
BEGIN {
use vars qw ($VERSION);
$VERSION= '0.01';
}
use Apache2::Const qw(:common);
sub handler {
my ( $r )= shift;
DEBUG && print STDERR "\n Apache2::xForwardedFor";
return DECLINED if $r->uri eq '/favicon.ico';
my $x_forwarded_for__header_name= $r->dir_config->get('xForwardedForAlternateHeaderName') || 'X-Forwarded-For' ;
my $require_header= $r->dir_config->get('xForwardedForRequire') || undef;
# for testing purposes, toss in a local header value
TEST && $r->headers_in->set( $x_forwarded_for__header_name=> '10.0.1.140' );
my $x_forwarded_for__header_value= $r->headers_in->{ $x_forwarded_for__header_name };
# if we are requiring a header to be sent, and its not there, fail immediately
if ( $require_header ) {
DEBUG && print STDERR "\nRequire: true";
if ( !$x_forwarded_for__header_value ) {
DEBUG && print STDERR "\n \theader missing";
return FORBIDDEN;
}
}
# if we are requiring an additional header to be sent, and its not there or doesn't match, fail immediately
if ( my $require_header_other_name= $r->dir_config->get('xForwardedForRequireHeaderName') ) {
TEST > 1 && $r->headers_in->set( $require_header_other_name=> $r->dir_config->get('xForwardedForRequireHeaderValue') );
DEBUG && print STDERR "\nRequire Additional Header: true";
my $require_header_other_value= $r->headers_in->{ $require_header_other_name };
if (
!$require_header_other_value
||
( $require_header_other_value ne $r->dir_config->get('xForwardedForRequireHeaderValue') )
)
{
DEBUG && print STDERR "\n \tadditional header missing or invalid";
return FORBIDDEN;
}
};
# Block based on Remove / Add AcceptForwarder values
my $_accept= 0;
my $remote_ip= $r->connection->remote_ip ;
TEST && ( $remote_ip= '192.168.1.2');
DEBUG && print STDERR "\n remote_ip__proxy: ". $remote_ip;
my %ips_accept= map { $_=> 1 } $r->dir_config->get('xForwardedForAccept');
if ( exists $ips_accept{$remote_ip} ) {
$_accept= 1;
}
my %ips_deny= map { $_=> 1 } $r->dir_config->get('xForwardedForDeny');
if ( exists $ips_deny{$remote_ip} ) {
$_accept= -1;
}
if ( $_accept < 0 ) {
DEBUG && print STDERR "\n ip in blocked list";
return FORBIDDEN;
}
elsif ( !$_accept && $require_header) {
DEBUG && print STDERR "\n ip not passed, and header required";
return FORBIDDEN;
}
elsif ( !$_accept && !$require_header) {
DEBUG && print STDERR "\n ip not passed, but header not required";
}
DEBUG && print STDERR "\n x_forwarded_for__header_value: ".$x_forwarded_for__header_value;
# Extract the desired IP address
if ( my ($ip)= $x_forwarded_for__header_value=~ /^([\d\.]+)/ ) {
DEBUG && print STDERR "\n original remote_ip: ". $remote_ip;
$r->connection->remote_ip($ip);
DEBUG && print STDERR "\n new remote_ip: ".$r->connection->remote_ip;
}
else {
# do nothing if no ip is in forwarded-for header
# should we toss an error if this is because we couldn't parse an ip, but the header was there?
DEBUG && print STDERR "\n no ip change";
}
# stacked handlers should still run off this
return OK;
};
=head1 NAME
Apache2::xForwardedFor - Re-set remote_ip to incoming client's ip when running mod_perl behind a reverse proxy server.
In other words, copy the first IP from B header, which was set by your reverse proxy server,
to the B connection property.
=head1 SYNOPSIS
in httpd.conf
PerlModule Apache2::xForwardedFor
PerlSetVar xForwardedForRequire 1
PerlSetVar xForwardedForAccept 192.168.1.1
PerlAddVar xForwardedForAccept 192.168.1.2
PerlSetVar xForwardedForRequireHeaderName X-Internal-Password
PerlSetVar xForwardedForRequireHeaderValue shibby
PerlPostReadRequestH
Re: chown executed by the apache user
You could run the chown command using sudo if you are on *ix. http://www.courtesan.com/sudo/sudo.html Tom Christian Hauser schrieb: > Basel, Donnerstag, 3. August 2006, 07:51:47 > . > > *chown executed by the apache user* > > > Hello Mod_Perl List > > > I need to change the uid, 'chown' for a file via the apache-perl > process. > > People can work via FTP/WebDAV on files, but also via a Web Interface. > For the web I have basic authentication, and of course when touching a > file, it has the uid of the Apache process. As I use the FS to keep > owner information, that's not what I want! > > Afaik I can only 'chown' while being root. An to become root (what I > wouldn't like, but would do if it would solve the problem) again I > would need to be root. An of course I will never let the Apache > running as root. > > How would you solve that problem? > > mod_perl 1.0, Apache 1.x > > . > > Best Regards, Christian - [EMAIL PROTECTED] - > > > > > signature.asc Description: PGP signature
