Basic authentication
Hi,
I'm having a bit of trouble authenticating users. The script I have works, but only a
couple of times before it just sends out 401 without prompting the user for their
details. We have mod_perl 1.99_05 installed, we don't want to upgrade as we would have
more applications to upgrade than time.
Any help/questions would be appreciated. The problem script is below:
use strict;
use Apache::Const qw(OK AUTH_REQUIRED);
use lib qw(/var/www/html/opbms/libs);
use CheckLogin;
use CreateFrames;
my $r = shift;
print Content-Type:text/html\n\n;
my ($status, $password) = $r-get_basic_auth_pw;
if ($status != OK)
{
$r-status($status);
exit($status);
}
my $ip = '127.0.0.1';
my $port = 31555;
if (CheckLogin::Check($r-user, $password, $port, $ip) eq '1')
{
CreateFrames::Create($r-user, $password, $port, $ip);
}
else
{
$r-note_basic_auth_failure;
$r-status(AUTH_REQUIRED);
exit(AUTH_REQUIRED);
}
Cheers!!
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
Re: Basic authentication
Stephen Hardisty wrote:
Hi,
I'm having a bit of trouble authenticating users. The script I have works, but only a
couple of times before it just sends out 401 without prompting the user for their
details. We have mod_perl 1.99_05 installed, we don't want to upgrade as we would have
more applications to upgrade than time.
Any help/questions would be appreciated. The problem script is below:
use strict;
use Apache::Const qw(OK AUTH_REQUIRED);
use lib qw(/var/www/html/opbms/libs);
use CheckLogin;
use CreateFrames;
my $r = shift;
print Content-Type:text/html\n\n;
don't do that - AUTH_REQUIRED is an error status, so apache will send it's
own set of headers.
my ($status, $password) = $r-get_basic_auth_pw;
if ($status != OK)
{
$r-status($status);
exit($status);
}
yike!
you shouldn't ever play with $r-status. calling exit is also not the
standard way.
examples of auth handlers abound, so you should really just be following
them - even though you are using mod_perl 2.0, the API is really the same
wrt get_basic_auth_pw() etc.
some examples include the many, many modules on CPAN. you can also find
detailed auth examples in
http://www.modperlcookbook.org/chapters/ch13.pdf
and
http://www.modperlcookbook.org/code/ch13/
specifically
http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm
HTH
--Geoff
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 9:37 AM -0400, Michael [EMAIL PROTECTED] wrote: The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). So the database connection has to persist from the mod_perl authentication scheme to the backend software? Interesting... Does that work? This isn't really an issue with database connections. It's just the authentication data/method that needs to persist for both. And that is handled by a cookie/ticket authentication. Thanks to Cees Hek [EMAIL PROTECTED] for helping me find a module I had lost track of. The module is mod_auth_tkt and can be found here: http://www.openfusion.com.au/labs/mod_auth_tkt/ I'm on my way to having an elegant solution now. Thanks to all who responded. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 9:45 AM -0400, Michael [EMAIL PROTECTED] wrote: Any other suggestions? I'd think you'd want to have the same authentication process for both, and a shared database (or something) to store the session data. Have the front-end do the login part, pass the client to the backend, which discovers that the client is already authenticated. Using tickets for authentication will work with both the front and backend servers. I was having problems finding a solution which had an apache module (written in C) plus support/examples for perl to use in the backend. With thanks to Cees Hek [EMAIL PROTECTED] I found mod_auth_tkt which does just what I need. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good morning, On 26/8/03 at 8:26 PM +0200, Thomas Klausner [EMAIL PROTECTED] wrote: Hi! On Die, Aug 26, 2003 at 09:06:05 +1000, Charlie Garrison wrote: I need to protect resources in both the static (proxy) front-end and the mod_perl back-end. I have been using standard http authentication which works pretty well except for not allowing a proper logout function and some caching issues which result in occasional false FORBIDDEN responses. Since a proper logout has become an important requirement, I am looking for other solutions. Did you take a look at Apache::AuthCookie? http://search.cpan.org/author/MSCHOUT/Apache-AuthCookie-3.04/ Yes, I've looked at Auth::Cookie, and if I needed a mod_perl only solution, it would be perfect. Since I need the user credentials in the mod_perl app, I'm not happy to leave all authentication to the front-end proxy server unless it sets the user credentials (or some other values) before passing along the request. As AuthCookie is a mod_perl handler, you would have to put the Authentification into the backend. Depending on how you generate the session key (i.e. the value of the Auth Cookie), you should be able to use the cookie in the frontend using one of the modules you mentioned (although I don't know any of them..) Which sort of brings me back full circle. I'm happy to write the backend (modperl) support myself for whatever the frontend module requires. But the module that I would choose (mod_auth_mda) doesn't have perl examples for creating the MD5 cookie, and I'm only borderline confident that I can take their java examples along with the documentation to figure out perl routines for the cookie creation. I'm still hoping someone has already solved this issue of shared authentication scheme between static frontend and modperl backend servers. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said... The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. I feel that someone must have already solved this issue so any suggestions or advice would be appreciated. Are there any modules which I have missed? Are the perceived problems with the above modules really an issue, or should I be able to use one of them without any problems. I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple process. Right now I have one method that uses cookies in one module, another that uses cookies but splits things up into separate modules, and a third that adds a (md5 hash) parameter to the URI. All work very well, though I prefer the cookie method myself. If there's really nothing out there to add a hash to the URI, I could probably be convinced to package up the code I have, simple as it may be. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org Knowledge is power. Power corrupts. Study hard. Be Evil. - Thyra -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Quoting Michael [EMAIL PROTECTED]: On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said... The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). Cheers, Cees -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 2:49 PM +1000, Cees Hek [EMAIL PROTECTED] wrote: Umm, use Apache::DBI, that's what it's for. It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). Thanks for the clarification. And the requirement for something that works in both modperl and non-modperl servers is also part of the subject line. But I'll try to make the problem/requirements more clear in future emails. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 12:05 AM -0400, Michael [EMAIL PROTECTED] wrote: The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. Except that I'm looking for a solution which will also work in the static (proxy) front-end. I'm currently using Apache::DBI for the backend and it works well. I also want a solution which doesn't rely on browser based http authentication since logging out is a requirement. I feel that someone must have already solved this issue so any suggestions or advice would be appreciated. Are there any modules which I have missed? Are the perceived problems with the above modules really an issue, or should I be able to use one of them without any problems. I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple process. Right now I have one method that uses cookies in one module, another that uses cookies but splits things up into separate modules, and a third that adds a (md5 hash) parameter to the URI. All work very well, though I prefer the cookie method myself. Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. Any other suggestions? Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and staticfrontend
Hi there, On Wed, 27 Aug 2003, Charlie Garrison wrote: Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. It's not so hard. There's a skeleton module in the Apache sources for you to start with, take a look at it. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Wed, Aug 27, 2003 at 14:49:05, Cees Hek said... It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. Whoops, you're right, I did just skim it. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). So the database connection has to persist from the mod_perl authentication scheme to the backend software? Interesting... Does that work? -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org If Bill Gates had a nickel for every time Windows crashed... ..oh wait, he does. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Wed, Aug 27, 2003 at 15:45:11, Charlie Garrison said... I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. Any other suggestions? I'd think you'd want to have the same authentication process for both, and a shared database (or something) to store the session data. Have the front-end do the login part, pass the client to the backend, which discovers that the client is already authenticated. Are you looking for something that's just a drop-in solution, transparent to the backend completely, not part of the backend software? I'd think in that case, you'd want something like PerlAuthenHandler and PerlAuthzHandler, let them manage the logins and just pass the client down to the backend software. I could still be way off here though. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Ticket/cookie based authentication for mod_perl and static frontend
Good evening, I have done a bit of research and found some possible solutions, but none of them seem to be exactly what I want. First, the problem I need to solve... I need to protect resources in both the static (proxy) front-end and the mod_perl back-end. I have been using standard http authentication which works pretty well except for not allowing a proper logout function and some caching issues which result in occasional false FORBIDDEN responses. Since a proper logout has become an important requirement, I am looking for other solutions. Since I need the user credentials in the mod_perl app, I'm not happy to leave all authentication to the front-end proxy server unless it sets the user credentials (or some other values) before passing along the request. I have looked at the following apache modules (for v1.3): Cookie Authentication Version 1.9 Fake Basic Authentication using Cookies Module homepage at ftp://ftp.kciLink.com/pub/mod_auth_cookie.c.gz Cookie Authentication with MySQLVersion 1.0 Authentication against a MySQL database with a cryptographically secure cookie. Module homepage at http://www.qwk.net/opensource/mod_auth_cookie_mysql/ mod_auth_mdaVersion 2.1 Realms for document tree and fast login for user using MD5 signed cookies. Module homepage at http://www.frogdot.org/mod_auth_mda/ The first one, Cookie Authentication, looks nice and simple and should do what I want. It sets the user credentials from a cookie to be processed by another module in the request chain. But I'd prefer to have the authentication handled by the same module. There are some caching issues with the current auth module which I'd like to avoid (by not using the current module any longer). The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. The third one, mod_auth_mda, is probably my favourite choice (for a variety of reasons). But it doesn't have any sample code for creating the MD5 signed cookies with perl, and I'm not sure I feel confident about creating the needed functions myself. All the sample code is written in Java. Additionally, all of the above solutions require the use of cookies. It would be nice if I could also use a URI (eg. path info) rather than just a cookie solution. I feel that someone must have already solved this issue so any suggestions or advice would be appreciated. Are there any modules which I have missed? Are the perceived problems with the above modules really an issue, or should I be able to use one of them without any problems. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Hi!
On Die, Aug 26, 2003 at 09:06:05 +1000, Charlie Garrison wrote:
I need to protect resources in both the static (proxy) front-end and the
mod_perl back-end. I have been using standard http authentication which works
pretty well except for not allowing a proper logout function and some caching
issues which result in occasional false FORBIDDEN responses. Since a proper
logout has become an important requirement, I am looking for other solutions.
Did you take a look at Apache::AuthCookie?
http://search.cpan.org/author/MSCHOUT/Apache-AuthCookie-3.04/
Since I need the user credentials in the mod_perl app, I'm not happy to leave
all authentication to the front-end proxy server unless it sets the user
credentials (or some other values) before passing along the request.
As AuthCookie is a mod_perl handler, you would have to put the
Authentification into the backend. Depending on how you generate the session
key (i.e. the value of the Auth Cookie), you should be able to use the
cookie in the frontend using one of the modules you mentioned (although I
don't know any of them..)
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
authentication realms in http and https
We recently upgraded our webserver from Apache 1.3.6 / modperl 1.19 to Apache 1.3.27 / modperl 1.27 We use a .htaccess file in a directory to have a modperl script do authentication for directory access (for downloading files, etc.). It also redirects the user from http to https if he does not come in through https. On our old server, the user would only see the browser's login box once when he came in through http and was redirected to https. On the new server, however, the user has to login twice. But if the user comes in through https on the new server, there is only one login. So my guess is that the new server is not treating an authentication realm in http as the same as one in https. So, my question is... Is this different treatment of the http/https authentication realms something that changed in the newer version of modperl (or possibly apache)? Or is this something that can be changed through configuration options? (and also... is my analysis even correct? :) ) Thanks! -Jason Fong
Re: mp2: architectural question re authentication handlers
Quoting Carl Brewer [EMAIL PROTECTED]: Forgive me for asking yet another fundamentally basic question. I'm cutting a web app over from PHP to mod_perl 2, and am wondering how 'best' (for which there are many flavours ...) to handle authentication. At present I've knocked up a site that does auth via a form and state tracking with Session.pm. The form checks usernames passwords against a MySQL database, and the state is maintained by Session. This seems quite logical to me, coming from essentially a CGI background, but the discussion of handlers around here makes me believe there's a better way? I would highly recommend the Eagle book if you are looking to move beyond CGI when using mod_perl. I know that you are looking at mod_perl2, and the Eagle book does not cover mod_perl2, but it will give you great insight into how mod_perl and Apache works. And lucky for you, since you are interested in Authentication and Authorization, that chapter happens to be available online. http://modperl.com:9000/book/chapters/ch6.html Also checkout the great documentation available at http://perl.apache.org/ If you want a good example of how to implement Authentication and Authorization in mod_perl, then look on CPAN for the man Apache::Auth* modules. I have used Apache::AuthCookie in many projects and it has relatively good documentation. You will also find tonnes of info on Authentication if you search the mailing list archives. I see threads here discussing the use of handlers, which I don't really understand how they fit into the picture, they seem to my poor understanding to be a hardcoded chunk in httpd.conf, for handling authentation/state. Is there anywhere a dumb beginers guide to how this works? The easiest way to explain it is to just look at Apache's Basic Authentication support at first. The one where the browser pops up a window and you type in your username and password, and Apache authenticates the user for you before it will allow the CGI script to be executed or the html file to be downloaded. You configure that in httpd.conf or in .htaccess files, telling Apache who has access to specific files and directories. This is just your standard access control stuff. Now imagine that you can use that same core functionality in Apache, but write the routines yourself in perl. And instead of the ugly login popup you can instead create an HTML login page. Do they set environment variables or something that a script can then look for that the script can be sure is legit? Yes, they set the HTTP_USER variable to the users login when a user is authenticated. But your script doesn't need to even worry about that, because Apache won't execute the script unless the user is authorized. So if the script is executing, then the user is authenticated... for now I'm continuing with my form based authentication, but is there a 'better' way? And if so, what makes it better? The biggest benefit I find is that you can separate your authentication code from the rest of the code. With an Authentication handler, your CGI script or content handler will never even be executed unless the user has been authenticated. Also, how would you use a CGI based authentication scheme to limit access to a static HTML file, or an image? It can't be done cleanly. But with Authentication handlers, you can hook them to a Location or Directory directive or even a Files directive in the httpd.conf file. So you can protect an entire directory with ease. Cheers, Cees
Re: mp2: architectural question re authentication handlers
Cees Hek wrote: [chomp] Thanks Cees, that's exactly what I needed :) My stuff is all completely generated by scripts where I need access control, but I certainly see the use for controlling static entity access. Carl
mp2: architectural question re authentication handlers
Forgive me for asking yet another fundamentally basic question. I'm cutting a web app over from PHP to mod_perl 2, and am wondering how 'best' (for which there are many flavours ...) to handle authentication. At present I've knocked up a site that does auth via a form and state tracking with Session.pm. The form checks usernames passwords against a MySQL database, and the state is maintained by Session. This seems quite logical to me, coming from essentially a CGI background, but the discussion of handlers around here makes me believe there's a better way? I see threads here discussing the use of handlers, which I don't really understand how they fit into the picture, they seem to my poor understanding to be a hardcoded chunk in httpd.conf, for handling authentation/state. Is there anywhere a dumb beginers guide to how this works? Do they set environment variables or something that a script can then look for that the script can be sure is legit? Or am I completely missing the point? Do I need to buy a book? It seems really bad to go hacking into httpd.conf, but maybe that's just my old-school conservatism? for now I'm continuing with my form based authentication, but is there a 'better' way? And if so, what makes it better? Carl
Apache 2.1 Authentication Providers in Perl
hi all... buried within perl.com this week is my latest article http://www.perl.com/pub/a/2003/07/08/mod_perl.html which covers how to use Apache 2.1 authentication from Perl. one of the biggest benefits of Apache 2.1 auth over Apache 2.0 (or even 1.3) is the ease at which it opens up Digest auth, so if that is of interest to you then you really should check out the 2.1 Apache branch. the Apache::AuthenHook module the article discusses is on CPAN http://search.cpan.org/author/GEOFF/Apache-AuthenHook-2.00_01/ enjoy. --Geoff
dynamic Authentication with PerlHeaderParserHandler?
I tried to modify the Web agenda/calendar
chronos (http://chronoss.sourceforge.net) in such a way that everyone can
look at the calendar without authentication but changes need basic
authentication. In other words, URLs like
http://.../chronos?action=showday;
should go through without authentication and only if an URL like
http://.../chronos?action=editevent;
is requested, basic authentication takes place.
The only related think I found googling is
www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/Apache::Test_patch_P25603
where the use of PerlHeaderParserHandler is suggested. The code discussed in
this thread did not work out of the box, I append my version which works
with apache-1.3.27.
My question: Is this a good idea? Is there a better/more canonical way?
Many thanks, Meik
#-
package Auth;
#
# from httpd.conf:
#
# PerlHeaderParserHandler Auth
# AuthName Chronos # For some reason, this must be set.
# # AuthType is not set.
# # PerlAuthenHandler is not set
use Apache;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
return OK unless $r-is_initial_req;
# is this URL protected?
return OK unless is_protected($r);
# We got an answer using basic authentication
if ($r-header_in('Authorization')){
my ($res,$password) = $r-get_basic_auth_pw;
my $username = $r-connection-user;
... check ...
if( ... not_authorized ) {
$r-note_basic_auth_failure;
return AUTH_REQUIRED;
}
return OK;
}
# switch to basic authentication. This is the realm we really use.
$r-auth_name(Event Calendar);
$r-note_basic_auth_failure;
return AUTH_REQUIRED;
}
sub is_protected {
my $r= shift;
my $meth=$r-method;
my $args = $r-args;
return 1 if $meth =~ /POST/;
return 1 if $args=~ /delfile/;
return 0;
}
1;
--
Meik Hellmund
Institut fuer Mathematik, Uni Leipzig
e-mail: [EMAIL PROTECTED]
http://www.math.uni-leipzig.de/~hellmund
Re: dynamic Authentication with PerlHeaderParserHandler?
Meik Hellmund wrote: I tried to modify the Web agenda/calendar chronos (http://chronoss.sourceforge.net) in such a way that everyone can look at the calendar without authentication but changes need basic authentication. In other words, URLs like http://.../chronos?action=showday; should go through without authentication and only if an URL like http://.../chronos?action=editevent; is requested, basic authentication takes place. probably what you want is something similar to Recipe 13.5 in the Cookbook, Conditional Authentication. you can find all of chapter 13 online for free http://www.modperlcookbook.org/chapters.html HTH --Geoff
RE: Authentication design
Perrin Harkins wrote (in a discussion with Michael L. Artz): Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r-user just seemed more intuitive to me. Well, I'm not sure what's involved in determining $r-user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: [...] The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Isn't this more a matter of 'niceness'? Putting the session/user stuff in AuthenHandler and then setting the $r-user makes it clear where the authentication takes place. All other handlers just check if $r-user is set and need not to bother with sessions and stuff? Or is there something against this and would you be a supporter of having it all in the same handler? --Frank
Re: Authentication design
Perrin Harkins wrote: Well, I'm not sure what's involved in determining $r-user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: - Fetch the session key from the validated cookie. - Load the session using that key. - Grab the user ID from the session. - Load the user's data based on that ID. The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Not sure that I quite understand ... what do you mean by load the session/user data if it is being done in a handler before content phase? What would you use to store the retrieved data ... pnotes? Also, I am not quite sure of the distinction between session data and user data. Wouldn't session data be intrinsically tied to a user? My session table currently looks like [user_id, session_key, session_data, login_time, last_access_time]. I guess I am currently using the session table to be more of an authentication table, i.e. if you give me a good user_id/session_key ticket that matches what is in the database. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. -Otherwise, if there is a cookie, validate the cookie's user_id/session against the database one stored in the database. -If either the params or cookie passed muster, set $r-user and return Apache::OK. If the user passed incorrect parameters, redirect to a custom_error form which is the login page. Otherwise, return Apache::OK and do not set $r-user. within registry scripts: -If $r-user is set, turn on custom pages and load user preferences. -Mike
Re: Authentication design
There are at least 2 places where the idea can be improved to be even better: 1) for browsers that do not support cookie, embed the ticket/credential in the URL so the system works for all browsers 2) the part for ticket verification can be written in C so in case of dual-server setup (light plus proxy), which is kind of popular now, one can set it up in the light server to protect static content. Peter - Original Message - From: Michael L. Artz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 6:47 PM Subject: Re: Authentication design Well, sorta. I am actually using a custom module very similar to the one found in the cookbook (and AuthCookie, I think), i.e. create a PerlAuthenHandler that sets the custom error message to the login page and redirects you to it if you pass it an incorrect user/password request. If it the user/pass checks out, I set a session cookie (md5 sum of stuff), store the session_key in the database (Postgres), and set $r-user. If no user/password or cookie is presented, I just return OK for most of the site. A couple of scripts are login-only, and those are protected by an authz handler that makes sure $r-user is set. Everything is handled with my custom login forms, none of the crappy pop-ups for basic or digest authentication. So I guess that I am usurping the normal HTTP-authentication phase for my own nefarious purposes. I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? -Mike
RE: Authentication design
On Wed, 2003-06-11 at 03:32, Frank Maas wrote: The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Isn't this more a matter of 'niceness'? I'm not sure what you mean. Putting the session/user stuff in AuthenHandler and then setting the $r-user makes it clear where the authentication takes place. All other handlers just check if $r-user is set and need not to bother with sessions and stuff? Are you asking why anyone would get this on demand instead of always doing it in an auth handler? One reason might be that fetching the session and user is expensive, and you don't know if you'll need it or not just based on the URL. Or is there something against this and would you be a supporter of having it all in the same handler? If using a separate handler makes sense for your app and you like it that way, then do it. - Perrin
Re: Authentication design
On Wed, 2003-06-11 at 08:32, Michael L. Artz wrote: Not sure that I quite understand ... what do you mean by load the session/user data if it is being done in a handler before content phase? What would you use to store the retrieved data ... pnotes? That's what I've done in the past, although the users of the API didn't know that. We just made a get_session() method that returns the session. The first time it runs, it does the work. After that, it caches the session in pnotes() and gets it there for the remainder of the request. Also, I am not quite sure of the distinction between session data and user data. Wouldn't session data be intrinsically tied to a user? Don't you ever have to keep track of anything before you know who the user is? When I say user data I mean permanent data; things like the user's contact info and security allowances, not what's in page 2 of the form they are filling out. My session table currently looks like [user_id, session_key, session_data, login_time, last_access_time]. I guess I am currently using the session table to be more of an authentication table, i.e. if you give me a good user_id/session_key ticket that matches what is in the database. That's fine if it fits your requirements. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. Isn't the session key unique? Why put both in the cookie? -Otherwise, if there is a cookie, validate the cookie's user_id/session against the database one stored in the database. -If either the params or cookie passed muster, set $r-user and return Apache::OK. If the user passed incorrect parameters, redirect to a custom_error form which is the login page. Otherwise, return Apache::OK and do not set $r-user. within registry scripts: -If $r-user is set, turn on custom pages and load user preferences. That all sounds fine to me. - Perrin
Re: Authentication design
Hmm, I see now. I don't really care about users who aren't logged in, so I don't know that there is a need to store session data for them. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. Isn't the session key unique? Why put both in the cookie? Because my session table is indexed off the user_id. I know that it probably won't matter until I have something like 100+ nearly-simultaneous users, but I thought that it would be nice to plan ahead, just in case. I guess what I am hearing is the good-ole Perl adage: tmtowtdi. I think that what I have both works and seems to fit my needs just fine, so I will stick with it, just wanted to make sure that it wasn't glaringly horrible for some reason. Thanks to all who chimed in. -Mike
Re: Authentication design
Jonathan Gardner wrote: It sounds like you are mixing HTTP-level authentication with application-level authentication. Well, sorta. I am actually using a custom module very similar to the one found in the cookbook (and AuthCookie, I think), i.e. create a PerlAuthenHandler that sets the custom error message to the login page and redirects you to it if you pass it an incorrect user/password request. If it the user/pass checks out, I set a session cookie (md5 sum of stuff), store the session_key in the database (Postgres), and set $r-user. If no user/password or cookie is presented, I just return OK for most of the site. A couple of scripts are login-only, and those are protected by an authz handler that makes sure $r-user is set. Everything is handled with my custom login forms, none of the crappy pop-ups for basic or digest authentication. So I guess that I am usurping the normal HTTP-authentication phase for my own nefarious purposes. I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? -Mike
Re: Authentication design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 03 June 2003 18:59, Michael L. Artz wrote: I am trying to design/implement a fairly simple authentication scheme using cookies and such, but wanted to air my design questions before I run into too many issues. It sounds like you are mixing HTTP-level authentication with application-level authentication. While HTTP authentication is pretty cool, unfortunately it is user-unfriendly. You won't find hardly any big sites that use it for this reason. Instead, they use application-level authentication. This is like Slashdot's login box, where everything is handled with cookies and HTML forms. The idea here is that there is a hash attached to each user who browses the website. You store variables and information in that hash. When they come back, you restore the hash they used last time. There are several ways to do this. The best practice is to give the user a cookie that is a number -- usually an MD5 of something like time, PID of the server process, and other random bits of data. The idea is you want a unique, unguessable session id. Then, on your end, you create a table in a database or something like a database. You stoe the session id linked to the session data. But how to store a hash in a database? You serialize it with Data::Dumper. The algorithm on each page is pretty simple. If the user is browsing a page where you might want to use session data, just check for the session id cookie value. If it is not there, you have a choice: do you set a cookie for all users when they fail to show a session id cookie, or do you set it only under special circumstances (like when logging in)? Either way, you'll want to check to see if the cookie was properly set, and at least warn the user that cookies need to be enabled. The way I like to do this is to set the cookie, then redirect them to a cookie check page. The cookie check page will see if the cookie was set. If not, it prints out a warning and explains your privacy policy. The idea is to convince the user to change his browser setting to accept your cookies. If the cookie was successfully set, you redirect back to where you came from. Once you get the session id, you grab the session data, unserialize it, and begin using it. When you are done, remember to serialize the data, and store it in the database. With a little thought, you can probably tweak the system so that it does exactly what you need. Don't be afraid of exploring MySQL or PostgreSQL for storing the session data. If you are only going to store session IDs, I would suggest you explore MySQL. If you may get serious about the database, and one day, design a huge database, you are better off starting off with PostgreSQL. Enjoy! - -- Jonathan Gardner [EMAIL PROTECTED] (was [EMAIL PROTECTED]) Live Free, Use Linux! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+5eKLWgwF3QvpWNwRAoWdAKCc1HFa+jxbuiO5+lySY7ViKK7cBQCaA2m5 f7F/121dBpe7ULqyBszvxCI= =T9Cv -END PGP SIGNATURE-
Re: Authentication design
On Tue, 2003-06-10 at 21:47, Michael L. Artz wrote: I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? It is a good way to do it. The confusing bit is your use of $r-user, which is generally part of HTTP basic auth. Cookie-based auth schemes generally just use an ID in the cookie to tie into server-side data. I'm not certain it won't work to use $r-user, but I don't see the point when you already have a unique identifier in the cookie. - Perrin
Re: Authentication design
Perrin Harkins wrote: I'm not certain it won't work to use $r-user, but I don't see the point when you already have a unique identifier in the cookie. Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r-user just seemed more intuitive to me. -Mike
Re: Authentication design
On Tue, 2003-06-10 at 23:43, Michael L. Artz wrote: Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r-user just seemed more intuitive to me. Well, I'm not sure what's involved in determining $r-user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: - Fetch the session key from the validated cookie. - Load the session using that key. - Grab the user ID from the session. - Load the user's data based on that ID. The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. - Perrin
Authentication design
I am trying to design/implement a fairly simple authentication scheme using cookies and such, but wanted to air my design questions before I run into too many issues. I would like the site to be almost entirely publicly accessible, however if you log in you get special options in addition to the normal ones. Also, there are certain things that you can only do while logged in, like post comments. I figure that this is pretty standard. I currently have a PerlAuthenHandler that simply sets the $r-user if either the correct cookie was given or the correct user/pass parameters were passed (remarkably like the cookie authentication listed in the cookbook). It return Apache::OK on all cases except when the user/password parameters are invalid, in which case it redirects the user to the login page. I plan on using the $r-user as a test within my Apache::Registry scripts to see whether the user has successfully logged in and to display the options accordingly. My question basically centers around the best way to protect the only if you login pages. I was thinking of putting them in their own directory and protecting them with a tiny PerlAuthzHandler, which would scatter scripts of the same nature in two separate places (i.e. for comments, view-create-post), or protect the entire site with a PerlAuthzHandler that has a table of all of the only if you login pages, which has the drawback of having to change the handler every time I add a new script. Are there any other/better ways to do this? Thanks -Mike
RE: Authentication design
Hi Michael -- My question basically centers around the best way to protect the only if you login pages. I was thinking of putting them in their own directory and protecting them with a tiny PerlAuthzHandler, which would scatter scripts of the same nature in two separate places (i.e. for comments, view-create-post), or protect the entire site with a PerlAuthzHandler that has a table of all of the only if you login pages, which has the drawback of having to change the handler every time I add a new script. Are there any other/better ways to do this? Using the directory structure is a good way to solve this problem. It is the way Apache likes to work. Most of Apache's internal systems are oriented towards directory paths -- .htaccess, Location, Directory, etc. As a result, there are plenty of facilities for managing security in this fashion. HTH, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
[mp2] Authentication/Authorization modules
I am fairly new to mod_perl/apache, having grown up with OpenACS and AOLServer. I have read all of the docs on the web site (I think) and had a whole authentication/authorization scheme planned out using Apache::AuthCookie and Apache::Session. I was just put in charge of a beta web application (database backed, user preferences, etc), and would like to use Apache2/mp2 for it. I came to find that AuthCookie doesn't seem to be ported to mp2, so my origianal authorization plan went up in shambles, not to mention all of the other stuff that I have read (eagle book, developer's cookbook) seems to be centered around mp1 and libapreq. My newbie question is then, what would the best way to implement an authorization scheme in mp2 and are there any helpful modules ported? I am thinking of something pretty standard, like what Apache::AuthCookie provides with a DB backend verifying the user/pass. I attempted to implement something like recipe 13.7 (from the cookbook) using CGI::Cookie instead of Apache::Cookie, but CGI complained about not being able to find Apache.pm. I assume that I just need a newer version (using stock RH8.0 with new apache and mod_perl). Any help would be appreciated. Thanks -Mike
Re: [mp2] Authentication/Authorization modules
Michael L. Artz wrote: I am fairly new to mod_perl/apache, having grown up with OpenACS and AOLServer. I have read all of the docs on the web site (I think) and had a whole authentication/authorization scheme planned out using Apache::AuthCookie and Apache::Session. I was just put in charge of a beta web application (database backed, user preferences, etc), and would like to use Apache2/mp2 for it. I came to find that AuthCookie doesn't seem to be ported to mp2, so my origianal authorization plan went up in shambles, not to mention all of the other stuff that I have read (eagle book, developer's cookbook) seems to be centered around mp1 and libapreq. My newbie question is then, what would the best way to implement an authorization scheme in mp2 and are there any helpful modules ported? I am thinking of something pretty standard, like what Apache::AuthCookie provides with a DB backend verifying the user/pass. I attempted to implement something like recipe 13.7 (from the cookbook) using CGI::Cookie instead of Apache::Cookie, but CGI complained about not being able to find Apache.pm. I assume that I just need a newer version (using stock RH8.0 with new apache and mod_perl). You should be able to use CGI::Cookie with the latest CGI.pm and the latest mod_perl (1.99_08 or cvs). Certainly it'd be helpful for module authors to start porting their modules to mp2. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Problems with custom authentication module
Title: Message Hi, I'm writing my own authentication module that uses Oracle and special encryption to handle passwords, it uses pretty much the same code as AuthDBI except for a few changes. Everything was running smoothly until I tried to make a mod_perl handler be the 401 ErrorDocument. If I do that, the authen handler returns 401 on every request and the 401 page is displayed without ever popping up the auth box. If I make the 401 ErrorDocument a regular HTML page, I will get the 3 chances at the popup box unless I do not send across a username and in that case it goes straight to the 401 page (possibly a problem with my code). HOWEVER, if I use an htpasswd file to do authentication and set the mod_perl handler to the 401 page, it works perfectly. Can anyone tell me where I might be going wrong? I'm having a hell of a time tracking this one down. Thanks, Brian Hann
Re: Override Authentication for one sub directory
Scott Alexander wrote: Hi, I'm using Apache-AuthCookie-3.04 for authentication I have a protected directory with 10 sub directories, one directory needs to be open to any user. I could write 10 Directory /usr/local/systems/work/directory_1 or use a PERL section in the conf file to create the 10 directory directives. Can I override the settings for one directory somehow? So any user with no login or password will get in. Actually I don't even want the login prompt to appear. we talk about this in the cookbook - recipe 13.5. basically, you need to disable authentication for the directories in question. see http://www.modperlcookbook.org/code/ch13/Cookbook/PassLocalIP.pm for the example from the book, which disables auth phases for allowed IPs. also keep in mind the Satisfy Any directive, which is what you probably should use if you're thinking about IP based stuff :) HTH --Geoff
Re: Override Authentication for one sub directory
This might be a bit OT, but since I've read somewhere on apache.org that Apache2 was using the same regex engine as Perl 5's... So I'm under the impression that with Apache2 you could do something like: DirectoryMatch ^/usr/local/systems/works/(?!open/) # your auth handler goes here /DirectoryMatch Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Override Authentication for one sub directory
Hi, I'm using Apache-AuthCookie-3.04 for authentication I have a protected directory with 10 sub directories, one directory needs to be open to any user. I could write 10 Directory /usr/local/systems/work/directory_1 or use a PERL section in the conf file to create the 10 directory directives. Can I override the settings for one directory somehow? So any user with no login or password will get in. Actually I don't even want the login prompt to appear. In my httpd.conf file I have Directory /usr/local/systems/work/ PerlSendHeader On SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI AuthType Apache::Authenticate AuthName protected PerlAuthenHandler Apache::Authenticate-authenticate require valid-user /Directory Directory /usr/local/systems/work/open/ # in this directory I need to allow any user /Directory Thanks Scott
RE: Cookie-free authentication
On Fri, 13 Dec 2002 20:19:55 -0800 (PST), Bill Moseley wrote: Hi Bill On Sat, 14 Dec 2002, Ron Savage wrote: Under Apache V 1/Perl 5.6.0 I could not get the Apache::AuthCookieURL option working which munged URLs without requiring cookies. I thought the problem was that Apache::AuthCookie was redirecting to your login scrip on logout instead of displaying your logout page. Yes, this is one problem. PS My email/internet access at the office has been discontinued while I'm 'between contracts'. -- Cheers Ron Savage, [EMAIL PROTECTED] on 17/12/2002 http://savage.net.au/index.html
RE: Cookie-free authentication
On Thu, 12 Dec 2002 14:29:16 -, Peter Werner wrote: hi all Hi Peter, et al [snip] i suppose it really depends on what you are developing, but take heed. i fully understand why cookie based authentication may be unacceptable, but consider maintainability and (long-term) scalability when you're doing your design and implementation. in the end you'll save someone a few grey hairs [snip] documentation :). however, it seems to me that (for clients that can support this implementation of Digest, which seems to be just about everyone but MSIE) the nonce provides exactly the kind of state information that is required for login/logout authentication. of course, it trades cookies for that pop-up box (again), so if you're looking for cookiless, HTML form based logins, then it's probably not what you want. All comments highly appreciated. It's a university environment, with MSIE on all PCs. Under Apache V 1/Perl 5.6.0 I could not get the Apache::AuthCookieURL option working which munged URLs without requiring cookies. I've just upgraded to Apache V 2/Perl 5.8.0 and fought off a dept-wide Klez attack, with McAfee lying about having cleaned the machines, so one day soon I'll retry AuthCookieURL. -- Cheers Ron Savage, [EMAIL PROTECTED] on 14/12/2002 http://savage.net.au/index.html
RE: Cookie-free authentication
On Sat, 14 Dec 2002, Ron Savage wrote: Under Apache V 1/Perl 5.6.0 I could not get the Apache::AuthCookieURL option working which munged URLs without requiring cookies. I thought the problem was that Apache::AuthCookie was redirecting to your login scrip on logout instead of displaying your logout page. -- Bill Moseley [EMAIL PROTECTED]
Cookie-free authentication
Ron Savage wrote: On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote: [snip] Some of us are trying to implement authentication/login/logout where, if at all possible, cookies are not to be used. A cookie-free discussion would be most welcome. I've done a bit of preliminary work with using Digest authentication to accomplish this - see Session.pm in Apache::AuthDigest, the latest copy of which can be found here http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDigest-0.022.tar.gz it's fairly new interface, and I've only toyed with it (though there is _some_ documentation :). however, it seems to me that (for clients that can support this implementation of Digest, which seems to be just about everyone but MSIE) the nonce provides exactly the kind of state information that is required for login/logout authentication. of course, it trades cookies for that pop-up box (again), so if you're looking for cookiless, HTML form based logins, then it's probably not what you want. --Geoff
RE: Cookie-free authentication
hi all www.wgsn.com is a subscription based service that doesn't use cookies for authentication. we use basic auth. I would like to share what i consider how not to implement cookie-free authentication. there are three tiers to our website tier 1 is apache with mod_perl doing authentication and mod_proxy passing requests to tier 2 tier 2 is a content management server tier 3 is the database server. tier 3 stores the raw content, tier 2 puts the bits from the db server together and tier 1 logs the hit and sends it to the client, nothing too fancy here. our authentication has two main bits that suck. first is subscribers have their username and password mapped to a special username and password for the content management systems, which differs on varying levels of subscriptions. as an example, the apache servers may recognize n valid usernames and passwords, while the cms only recognizes 3. this mapping is done via an apache module written in perl, which talks to a series of perl scripts that keep a copy of the user database. when a request comes in to the apache servers, the module maps the customer username/pass to the content management username/pass, rewrites the Authorization: header, and mod_proxy sends the request to tier 2. this sounds reasonably simple, but in the real world it's one big bit of mush of unpleasant stuff that falls over every other week. why that is i've never been able to exactly put my finger on, but i have a feeling it was developers letting their personal preferences getting in the way of business needs, by ignoring existing standards or best practices, and going out to re-invent a better wheel. the second (and imo bigger) bit that sucks is because we do silly things like re-writing incoming http headers and cleaning them as the response goes back out, we can't utilize things like caching as effectively as we could if we were using cookies. the reason for this is due to our requirement that we must see which users are accessing which areas of the site (so we can see what's popular etc). The information we require is stored in these re-written headers. This means we need our downstream caching hierarchy (which is a 3rd party) to send at least an If-Modified-Since request for images (some of which we allow to be cached), and we cannot allow them to cache our html documents. If we used cookies our caches could authenticate log hits at the caching server nearest the client instead of having to come back to our origin servers for every single hit. in busy periods we serve around 2.5 million objects a day, nothing really major, but enough to make things like this a significant drain on our resources (which are limited as always :) for the reasons above, we are investigating the transition to cookie based authentication. i suppose it really depends on what you are developing, but take heed. i fully understand why cookie based authentication may be unacceptable, but consider maintainability and (long-term) scalability when you're doing your design and implementation. in the end you'll save someone a few grey hairs :) -pete -Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 12, 2002 1:44 PM To: Ron Savage Cc: Apache mod_perl Subject: Cookie-free authentication Ron Savage wrote: On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote: [snip] Some of us are trying to implement authentication/login/logout where, if at all possible, cookies are not to be used. A cookie-free discussion would be most welcome. I've done a bit of preliminary work with using Digest authentication to accomplish this - see Session.pm in Apache::AuthDigest, the latest copy of which can be found here http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDiges t-0.022.tar.gz it's fairly new interface, and I've only toyed with it (though there is _some_ documentation :). however, it seems to me that (for clients that can support this implementation of Digest, which seems to be just about everyone but MSIE) the nonce provides exactly the kind of state information that is required for login/logout authentication. of course, it trades cookies for that pop-up box (again), so if you're looking for cookiless, HTML form based logins, then it's probably not what you want. --Geoff
undesired authentication timeout behavior
I am using a homegrown subclass of AuthCookieDBI for authentication. So far so good. But I have a problem that I hope someone can offer guidance on. For now I have the auth set to expire after a certain amount of time. After the expiration, the next time the user clicks, the login form comes up, which is proper and working. But the site uses frames, and the login comes up in the frame that was clicked. Is there a way to force it to ignore the frames, treat the browser window as having no frames, and then redirect back to the frame configuration it was in after authentication? I guess this probably is an issue with any mod_perl authentication scheme Thanks in advance, GV
Re: NTLM Authentication patch
I am also interested in this patch, as we encounter lots of problems with some POSTed forms over here. I just uploaded a new version with a fix to CPAN: The URL ftp://ftp.dev.ecos.de/pub/perl/ntlm/Apache-AuthenNTLM-0.23.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GR/GRICHTER/Apache-AuthenNTLM-0.23.tar.gz size: 49682 bytes md5: 6a0e59d24b23737b2902e6cd43aceb77 Gerald, was the logfile I sent you helpful? Yes, thanks Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: NTLM Authentication patch
Hello, I am also interested in this patch, as we encounter lots of problems with some POSTed forms over here. Sometimes we get several Inernal Server Errors until the form gets processed correctly. It usually is enough to click on 'Reload' to get the form processed. This behaviour occurs only using IE 5.5SP2 (Exact version: 5.50.4807.2300). Mozilla is working fine, obviusly without using NTLM... Gerald, was the logfile I sent you helpful? Thanks, Frank - Weitergeleitet von Frank Zimper/BUH/CH/SB_PLC am 27.11.2002 14:17 - Gerald Richter [EMAIL PROTECTED] 11.11.2002 09:33 An: Gerald Combs [EMAIL PROTECTED], [EMAIL PROTECTED] Kopie: Thema: Re: NTLM Authentication patch We recently installed AuthenNTLM where I work, and ran into the POST problems described in the thread at http://marc.theaimsgroup.com/?t=10317736546r=1w=2 After looking through a couple of network traces I think I've found the problem. It appears that after IE authenticates via NTLM, it sends type 1 messages for subsequent requests during a keepalive session. This is fine and dandy unless you're sending a POST request - when it sends the type 1 message, it also sends a Content-length: 0, and doesn't append the POST data. Since the browser has successfully authenticated itself earlier in the keepalive session, AuthenNTLM validates the request and a POST with no accompanying POST data gets passed to the server. Yes, I have seen the same from traces people have send me, but could not reproduce it here (my IE always sends the POST data) I have modified your patch to handle both situations and to have the old behaviour in case of GET requests (for performance reasons) I send you the updated version per private mail, please give it a try if it still works correct for you and let me know. I will release it to CPAN as soon as somebody who had had the problem reports me that the new version solves it. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: NTLM Authentication patch
We recently installed AuthenNTLM where I work, and ran into the POST problems described in the thread at http://marc.theaimsgroup.com/?t=10317736546r=1w=2 After looking through a couple of network traces I think I've found the problem. It appears that after IE authenticates via NTLM, it sends type 1 messages for subsequent requests during a keepalive session. This is fine and dandy unless you're sending a POST request - when it sends the type 1 message, it also sends a Content-length: 0, and doesn't append the POST data. Since the browser has successfully authenticated itself earlier in the keepalive session, AuthenNTLM validates the request and a POST with no accompanying POST data gets passed to the server. Yes, I have seen the same from traces people have send me, but could not reproduce it here (my IE always sends the POST data) I have modified your patch to handle both situations and to have the old behaviour in case of GET requests (for performance reasons) I send you the updated version per private mail, please give it a try if it still works correct for you and let me know. I will release it to CPAN as soon as somebody who had had the problem reports me that the new version solves it. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
NTLM Authentication patch
We recently installed AuthenNTLM where I work, and ran into the POST
problems described in the thread at
http://marc.theaimsgroup.com/?t=10317736546r=1w=2
After looking through a couple of network traces I think I've found the
problem. It appears that after IE authenticates via NTLM, it sends type 1
messages for subsequent requests during a keepalive session. This is fine
and dandy unless you're sending a POST request - when it sends the type 1
message, it also sends a Content-length: 0, and doesn't append the POST
data. Since the browser has successfully authenticated itself earlier in
the keepalive session, AuthenNTLM validates the request and a POST with no
accompanying POST data gets passed to the server.
Attached is a patch against the 0.21 release that fixes this behavior (in
our environment, at any rate). I know very little about NTLM
authentication and mod_perl coding, so the patch may not be entirely
correct.
--- /usr/local/perl/lib/site_perl/5.6.1/sun4-solaris/Apache/AuthenNTLM.pm Thu
Nov 7 17:29:15 2002
+++ ./AuthenNTLM.pm Tue Sep 3 11:03:04 2002
-502,21 +502,9
$conn - user($self-{mappedusername}) ;
# we accecpt the user because we are on the same connection
-$type = $self - get_msg ($r);
-print STDERR [$$] AuthenNTLM: OK because same connection pid = $$,
connection = $$conn cuser = .
-$conn - user . ' ip = ' . $conn - remote_ip . 'hash
= ' . $self - {usernthash} . \n if ($debug) ;
-
-
-# IE (5.5, 6.0, probably others) can send a type 1 message
-# after authenticating on the same connection. This is a
-# problem for POST messages, because IE also sends a
-# Content-length: 0 with no POST data.
-if (! $self - {ntlm} || (defined ($type) $type == 3) )
-{
-return OK ;
-}
-# Else fall through to the authentication below.
-
+print STDERR [$$] AuthenNTLM: OK because same connection pid = $$,
+connection = $$conn cuser = .
+$conn - user . ' ip = ' . $conn - remote_ip . \n
+if ($debug) ;
+return OK ;
}
}
radius ssl'ed authentication
Hello, I have a search engine that students can use to search for old exam papers. The papers can be served up if the student is accessing the papers from inside the university. If they are outside the university then they authenicate through Auth::LDAP. Unfortunately staff are asking for the same access now. I will have to use radius to authenticate staff and students. Also, this is the crunch, I now have to encrypt the login details for staff (and therefore students). Only the directory where the exam papers are kept are protected. I would like to carry on using the .htaccess file in that it lets the file be downloaded if the user is inside the university but then I would like to redirect to a secure server for the login process if the user is outside the university. It would be nice to only have the login process encrypted not the delivery of the papers. Where to start? Thanks, Owen.
Authentication Question
I have a mod_perl cgi script that I would like to get the username from the Apache server. The apache server successfully authenticates the client using Apache::AuthenSmb. How do I get this environment variable (the username) from apache into a variable in the perl script. Thanks, Brett
Re: Authentication Question
At 09:55 28.08.2002, Brett Hales wrote:
I have a mod_perl cgi script that I would like to get the username from
the Apache server. The apache server successfully authenticates the
client using Apache::AuthenSmb.
How do I get this environment variable (the username) from apache into a
variable in the perl script.
It's $ENV{REMOTE_USER} or $r-user
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Authentication Question
Please do not send replies directly to me, Cc the list.
At 13:40 28.08.2002, Brett Hales wrote:
On Wed, 2002-08-28 at 17:47, Per Einar Ellefsen wrote:
At 09:55 28.08.2002, Brett Hales wrote:
I have a mod_perl cgi script that I would like to get the username from
the Apache server. The apache server successfully authenticates the
client using Apache::AuthenSmb.
How do I get this environment variable (the username) from apache into a
variable in the perl script.
It's $ENV{REMOTE_USER} or $r-user
I have tried to use both of these,
$login_name = $ENV{REMOTE_USER};
and
$login_name = $r-user;
With the ENV I do not get anything when I print $login_name. With
$r-user I get the following in the error_log.
Cannot call method user without a package or object reference at
..
Do you have any advice, thanks again.
First of all: $r-user doesn't work because you haven't gotten the Apache
request object. To get it in an Apache::Registry script, insert:
my $r = Apache-request;
before your call to $r-user.
Why you aren't getting anything in $ENV{REMOTE_USER} I do not know. It
might be that the environment isn't set up that way in Apache::Registry. Or
maybe Apache::AuthenSmb doesn't set $r-user at all. Are you even nsure the
authentication is working?
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Optional HTTP Authentication ?
However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. Yes, however there are quite a number of issues with bookmarks and search engines... But that's for sure another interesting and less-ugly option. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. Yep. It's a shame that cookies which were a good idea at first get such a bad name because of all these moronic marketing companies which dream of knowing you inside out to send you more shit spam abuse them. But I'm off topic here :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some not unless you
use different URLs so the server knows when to request them?
The idea is that on a location which requires authentication I'll
redirect the user to a /login.html, or maybe a /?login=1 which will do
the following:
IF user is authenticated = redirect to location it came from
ELSE send 401 authorization required
This way users should get a login box strictly when necessary. Almost
all the request go thru an Apache::Registry friendly CGI script:
Alias /.static /opt/chico/static
Alias //opt/mkd/cgi/mkdoc.cgi/
Everything is treated using $ENV{PATH_INFO} in the script, and the
script knows when something needs authentication or not.
Note that you don't have to embed session info here, just add
some element to the URL that serves as the point where you
request credentials and omit it for people that don't log in. Or
redirect to a different vhost that always requires authentication but
serves the same data.
Oh but I have that already. I know that I need to password protect
/properties.html
/content.html
/move.html
/foo/properties.html
/foo/content.html
/foo/move.html
etc...
Is it possible to password-protect a class of URIs using regexes? That
would be another good option.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
From: Jean-Michel Hiver [EMAIL PROTECTED] Oh but I have that already. I know that I need to password protect /properties.html /content.html /move.html /foo/properties.html /foo/content.html /foo/move.html etc... Is it possible to password-protect a class of URIs using regexes? That would be another good option. I thought you meant that you wanted the same location to be accessed by different people with/without passwords. You should be able to put the authentication directives in a LocationMatch container in this case. Another approach would be to use mod_rewrite to map the request to a directory containing a symlink to the script and an appropriate .htaccess file. This is kind of brute-force but it lets you do anything you want with a request including proxying to an otherwise unreachable port or server for certain content. Unfortunately I think the symlink approach appears as a different script to mod_perl so it will cache a separate copy in memory. Les Mikesell [EMAIL PROTECTED]
Re: Optional HTTP Authentication ?
On Mon, Jul 01, 2002 at 10:30:36AM +0100, Jean-Michel Hiver wrote:
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some not unless you
use different URLs so the server knows when to request them?
The idea is that on a location which requires authentication I'll
redirect the user to a /login.html, or maybe a /?login=1 which will do
the following:
Umm... Perhaps I don't understand the significance of the login.html. Under
HTTP auth, if a page is protected via .htaccess then auth is immediatly
requested, and no redirect is possible.
More important is the fact that if a page does not require authentication,
the users login and password will not be sent. So a page like index.html that
is not normally authenticated will not receive the username, and no
a href=/adminAdmin this page/a will be possible.
I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
you could write some custom handler to handle the auth, but without a cookie
to note which users have authenticated, you might be out of luck.
Good luck,
Rob
Re: Optional HTTP Authentication ?
Thanks to the list and two days of hard work, I have my optional HTTP
authentication thingie working :-)
Basically here is how it looks in my apache config file:
# This method handler ensures that users must enter their credentials
# for any URI which looks like /foo/bar/login.html
LocationMatch .*/login.html$
AuthName MKDoc Login
AuthType Basic
PerlAuthenHandler MKDoc::Auth::SQL_HTTP-handler
require valid-user
/LocationMatch
# This method handler affects the whole site, it sets the
# $ENV{REMOTE_USER} variable if the credentials have been sent, or
# leave it undef otherwise.
Location /
PerlFixupHandler
MKDoc::Auth::SQL_HTTP-handler_opt
/Location
# if the user successfully logged in when hitting a /foo/bar/login.html
# location, then we want to redirect him where he came from
LocationMatch .*/login.html$
SetHandler perl-script
PerlHandler
MKDoc::Auth::SQL_HTTP-handler_redirect
require valid-user
/LocationMatch
more perl handlers here
* Now if you go to /properties.html BEFORE sending the credentials,
* You're redirected to /login.html?from=/properties.html where you login,
* Which redirects you to /properties.html... but this time your browser
sends the credentials!
This is interesting because it's up to the handlers to decide wether
they need authentication or not and does non depend on the location.
More important is the fact that if a page does not require authentication,
the users login and password will not be sent. So a page like index.html that
is not normally authenticated will not receive the username, and no
a href=/adminAdmin this page/a will be possible.
This is not true, once you've entered the credentials on /login.html the
browsers send them everywhere. Tested under Opera (Linux), Mozilla
(Linux) and IE from version 3 to version 6 (Windows), IE 3 (Mac),
Netscape 4 (Mac).
One exception: links :-(. But the browser support seems to be there...
In the future I plan to have some kind of hybrid handler which would
accept either HTTP credentials OR a cookie... that would be cool :-)
I'm not 100% sure this is possible without the use of cookies. I'm pretty sure
you could write some custom handler to handle the auth, but without a cookie
to note which users have authenticated, you might be out of luck.
Well I seem to have done it, so it must be possible thanks to you guys
;-. I will send the code to anyone who's interested but I don't want
to post it to the list because I suspect that most people aren't.
Thank you everyone,
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Hi there, On 30 Jun 2002, Randal L. Schwartz wrote: What? The EU is going to make cookies *illegal*? I highly doubt this. There is already EU legislation which might make the use of cookies suspect. It concerns, for example, the monitoring of individual keyboard operators to measure their performance. That's been illegal in the EU for some time. You only have to start counting your cookies to be treading on shaky ground. 73, Ged. BTW it's modperlatperldotapachedotorg
Re: Optional HTTP Authentication ?
Jean-Michel Hiver [EMAIL PROTECTED] writes: However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. Yes, however there are quite a number of issues with bookmarks and search engines... But that's for sure another interesting and less-ugly option. Very true. I was solving only the stated problem, and didn't think much about the other problems that would then appear. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. Yep. It's a shame that cookies which were a good idea at first get such a bad name because of all these moronic marketing companies which dream of knowing you inside out to send you more shit spam abuse them. But I'm off topic here :-) And that's all it is; a bad *name*. With the option to refuse to deliver cookies to a domain different from the domain of the top-level page, they have no actual problems. And they solve the problem they're supposed to solve nearly perfectly. Obviously for individual projects one has to do what the people with the checkbook say, but we shouldn't be just rolling over on cookies; we should be arguing the point strenuously. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: [OT] Optional HTTP Authentication ?
This seems a little off topic. I think this is an architecture question, not a mod perl question. Well, a bit of both I guess. Basically, you want all you protected files to be located in /protected or some other directory... No that is not possible. I am running a web application, there are no such things as 'files' (everything is done using PATH_INFO), only locations. Users can create as many locations as they want (i.e. /foo/bar/) and administrate them using URIs such as /foo/bar/properties.html, /foo/bar/contents.html, etc. There are some locations which do not need to be protected, i.e. /foo/bar/ /foo/bar/print.html /foo/bar/dc.xml /foo/bar/rss100.rdf But some others need to, like: /foo/bar/properties.html /foo/bar/contents.html /foo/bar/move.html etc. I want to use HTTP authentication for that, but of course I cannot password protect the whole site, because public users would not be so happy! Any ideas? -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Optional HTTP Authentication ?
Oh, I don't know, I think the poster was asking about how to produce this
effect with mod_perl. He wants to know *whether* a login was provided, even
on a *non-protected* page. That would let you say (while serving any old
page):
if( $ENV{REMOTE_USER} eq 'admin' ) {
$r-print('Yo, you can do a href=/admin/extra kewl stuff/a here.');
}
Yes, that is quite the case.
In one of the earlier stages of processing - maybe a FixupHandler or ? a
AuthenHandler might be appropriate - you can do something like this:
my $a = $r-header_in('Authorization');
$a =~ s/^Basic (.*)/$1/;
my( $user, $pass ) = split(':', decode_base64( $a ) );
if( check the username/password as you wish ) {
$ENV{REMOTE_USER} = $user;
}
So, now you can tell later during the request with a username/password was
offered (and you know it was a valid login/pass combo).
That's very interesting! I don't think I can use an auth handler because
then I would have to password protect the whole site (which I don't want
to).
I want to have just ONE page which is password protected (i.e.
/login.html). The page would just be a redirect, but once the user
entered his credentials then the browser should send them on the whole
site and then I could do the following:
/foo/properties.html
IF authenticated
IF authorized = trigger /foo/properties.html
ELSE = send custom error page
ELSE
redirect to /login.html?from=uri
Anyway I'm going to try that fixup handler thingie and I'll tell you how
it goes :-)
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
It seems that Apache::AuthCookie allows a way to make areas to which one can authenticate if s/he wants. I suppose that then in those areas you can tell if the user is logged in and affect the pages if so. Indeed the best option would be to be using one of the Apache::Session module and use the provided hash to store the login information. I have read the whole portion of the eagle book dedicated to authentication / authorization before posting my crack-smoked question to the list ;-) Unfortunatly: * For political reasons and compliance with future european legislation I cannot use cookies, * For usability reasons encoding session IDs on URIs would be really bad... users needs to be able to 'hack' the URIs without f***ing their sessions! Therefore I have to use HTTP authentication... Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Jean-Michel == Jean-Michel Hiver [EMAIL PROTECTED] writes: Jean-Michel * For political reasons and compliance with future european legislation Jean-Michel I cannot use cookies, What? The EU is going to make cookies *illegal*? I highly doubt this. Jean-Michel * For usability reasons encoding session IDs on URIs would be really Jean-Michel bad... users needs to be able to 'hack' the URIs without f***ing their Jean-Michel sessions! Why is a user hacking their URLs? Jean-Michel Therefore I have to use HTTP authentication... Even though the user/password is transmitted *in the clear* on *every single hit*, because you can't just use a session identifier? This is so very wrong from a security perspective. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Optional HTTP Authentication ?
What? The EU is going to make cookies *illegal*? I highly doubt this. Sorry, I am neither the lawyer nor the client, so I can't tell you... I know it's really stupid, but I am going to have to deal without cookies. Jean-Michel * For usability reasons encoding session IDs on URIs would be really Jean-Michel bad... users needs to be able to 'hack' the URIs without f***ing their Jean-Michel sessions! Why is a user hacking their URLs? I can answer that. http://www.useit.com/alertbox/990321.html cite * a domain name that is easy to remember and easy to spell * short URLs * easy-to-type URLs * URLs that visualize the site structure * URLs that are hackable to allow users to move to higher levels of the information architecture by hacking off the end of the URL * persistent URLs that don't change /cite i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412sid=56765454151 is not. Again it doesn't always make implementation easy :-/ Jean-Michel Therefore I have to use HTTP authentication... Even though the user/password is transmitted *in the clear* on *every single hit*, because you can't just use a session identifier? This is so very wrong from a security perspective. I have to agree with you on that. Cookies are probably far better than HTTP authentication. But I cannot use cookies. Period. I wish I could, because this was what I did in the first place and it was working fine! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Please check that the idea of this kind of authentication is to encrypt the ticket, instead of a plain session ID. If cookie is not available, having it on URI is a good idea. (Then one needs to have all links in a relative manner; see the Cookbook). Cookie itself does not make a secure session ID or a secure ticket. It is the encryption that does. Peter Bi - Original Message - From: Jean-Michel Hiver [EMAIL PROTECTED] To: Randal L. Schwartz [EMAIL PROTECTED] Cc: Jean-Michel Hiver [EMAIL PROTECTED]; Andrew Moore [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 30, 2002 10:07 AM Subject: Re: Optional HTTP Authentication ? What? The EU is going to make cookies *illegal*? I highly doubt this. Sorry, I am neither the lawyer nor the client, so I can't tell you... I know it's really stupid, but I am going to have to deal without cookies. Jean-Michel * For usability reasons encoding session IDs on URIs would be really Jean-Michel bad... users needs to be able to 'hack' the URIs without f***ing their Jean-Michel sessions! Why is a user hacking their URLs? I can answer that. http://www.useit.com/alertbox/990321.html cite * a domain name that is easy to remember and easy to spell * short URLs * easy-to-type URLs * URLs that visualize the site structure * URLs that are hackable to allow users to move to higher levels of the information architecture by hacking off the end of the URL * persistent URLs that don't change /cite i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412sid=56765454151 is not. Again it doesn't always make implementation easy :-/ Jean-Michel Therefore I have to use HTTP authentication... Even though the user/password is transmitted *in the clear* on *every single hit*, because you can't just use a session identifier? This is so very wrong from a security perspective. I have to agree with you on that. Cookies are probably far better than HTTP authentication. But I cannot use cookies. Period. I wish I could, because this was what I did in the first place and it was working fine! Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
Please check that the idea of this kind of authentication is to encrypt the
ticket, instead of a plain session ID. If cookie is not available, having
it on URI is a good idea. (Then one needs to have all links in a relative
manner; see the Cookbook). Cookie itself does not make a secure session ID
or a secure ticket. It is the encryption that does.
I *CANNOT* use cookies nor URIs for any kind of session tracking.
Otherwise I don't think I would have posted this message to the list in
the first place :-)
I agree that HTTP Basic authentication is totally and uterly ugly, but I
am going to have to stick with it no matter what... My problem is:
How do I tell apache to set the $ENV{REMOTE_USER} variable if the
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: [OT] Optional HTTP Authentication ?
In one of the earlier stages of processing - maybe a FixupHandler or ? a
AuthenHandler might be appropriate - you can do something like this:
my $a = $r-header_in('Authorization');
$a =~ s/^Basic (.*)/$1/;
my( $user, $pass ) = split(':', decode_base64( $a ) );
if( check the username/password as you wish ) {
$ENV{REMOTE_USER} = $user;
}
OK, I got this working using a fixup handler BUT there is a nasty trap.
It happens that the environment variables which you set from Perl aren't
inherited from sub-processes... which means that this technique is fine
if the script that comes after authentication runs under
Apache::Registry.
Unfortunately, I might need the script to run under mod_cgi... I
couldn't find how to tell the apache server to set environmental
variables in the mod_perl pocket reference, anyone has got an idea?
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
Jean-Michel Hiver [EMAIL PROTECTED] writes: Why is a user hacking their URLs? I can answer that. http://www.useit.com/alertbox/990321.html cite * a domain name that is easy to remember and easy to spell * short URLs * easy-to-type URLs * URLs that visualize the site structure * URLs that are hackable to allow users to move to higher levels of the information architecture by hacking off the end of the URL * persistent URLs that don't change /cite I generly agree with alertbox, and I agree in this instance. i.e. http://bigmegamarket.com/grocery/fruits/bananas/ is cool, http://bigmegamarket.com/index.pl?id=231223412sid=56765454151 is not. Both true. However, if the structure were http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas, say, with the number being the session ID, the URL then is hackable within that (good) definition. Again it doesn't always make implementation easy :-/ True enough; and my proposal is a bit harder to implement. I'm a big fan of cookies myself, for the thing they were made for, namely session tracking. I share your frustration :-(. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Optional HTTP Authentication ?
Hi, Jean-Michel: the official way to retrieve the remote user name under
Basic Authentication is to call for $r-connect-user(), or $r-user() in
mod_perl 2.0, I think. With a ticket authentication, one gets the user name
in the same way only AFTER the access control phase, because it is simulated
from the ticket, see e.g. my Apache::CookieAccess source at
modperl.home.att.net. BTW, for me, Basic Authnetication is not that ugly, it
is surpringly stable (than most of other Apache ideas) since day one.
Peter Bi
- Original Message -
From: Jean-Michel Hiver [EMAIL PROTECTED]
To: Peter Bi [EMAIL PROTECTED]
Cc: Jean-Michel Hiver [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, June 30, 2002 12:20 PM
Subject: Re: Optional HTTP Authentication ?
On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
Please check that the idea of this kind of authentication is to encrypt
the
ticket, instead of a plain session ID. If cookie is not available,
having
it on URI is a good idea. (Then one needs to have all links in a
relative
manner; see the Cookbook). Cookie itself does not make a secure session
ID
or a secure ticket. It is the encryption that does.
I *CANNOT* use cookies nor URIs for any kind of session tracking.
Otherwise I don't think I would have posted this message to the list in
the first place :-)
I agree that HTTP Basic authentication is totally and uterly ugly, but I
am going to have to stick with it no matter what... My problem is:
How do I tell apache to set the $ENV{REMOTE_USER} variable if the
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
Jean-Michel Hiver - Software Director
[EMAIL PROTECTED]
+44 (0)114 255 8097
VISIT HTTP://WWW.MKDOC.COM
Re: Optional HTTP Authentication ?
From: Jean-Michel Hiver [EMAIL PROTECTED]
I *CANNOT* use cookies nor URIs for any kind of session tracking.
Otherwise I don't think I would have posted this message to the list in
the first place :-)
I agree that HTTP Basic authentication is totally and uterly ugly, but I
am going to have to stick with it no matter what... My problem is:
How do I tell apache to set the $ENV{REMOTE_USER} variable if the
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some not unless you
use different URLs so the server knows when to request them?
Note that you don't have to embed session info here, just add
some element to the URL that serves as the point where you
request credentials and omit it for people that don't log in. Or
redirect to a different vhost that always requires authentication but
serves the same data.
Les Mikesell
[EMAIL PROTECTED]
Re: Setting require in Authentication handler?
I need to decide who has access based on the URI. I guess this means I can't use Apache's Basic auth module, since I can't dynamically set require. Does the cookbook have a code sample of checking the password for basic authentication? -Todd On Mon, 20 May 2002, Geoffrey Young wrote: Todd Chapman wrote: Can dir_config be used to set 'require' in an authentication handler? no. dir_config() provides access to a mod_perl specific table of variables, not generic Apache configuration directives. there is no API for setting the Require directive - it needs to be in your httpd.conf. I would then return DECLINED do that Apache's Basic auth handler would do the heavy lifting of checking the password. if you're looking to do conditional authentication what you really need to do is a bit backward - turn on all authentication hooks using the Require directive then use your handler to return OK when you don't want Apache to check the password. See recipe 13.5 in the cookbook for more information. the Satisfy any Apache directive may be able to help as well if you're using host-based criteria to determine whether you want to require a login. HTH --Geoff
Re: Setting require in Authentication handler?
That makes sense. I can't use mod_auth because I can't set Require. I'm using Basic authentication and text based password files. Unfortunately, I can't find an Apache::Auth* module that handles basic authentication against text files. Did I miss it somewhere? Thanks. -Todd On Mon, 20 May 2002, Geoffrey Young wrote: Does the cookbook have a code sample of checking the password for basic authentication? well, not via .htpasswd files, no. in general, it doesn't make much sense to use mod_perl to duplicate the same things that Apache already does for you, since the Apache code is faster, has had more eyeballs looking at it for longer, etc. in that sense you wouldn't want to write your own routine to just check a flat file. where mod_perl really shines wrt authentication is with all the other things Perl does well, such as using DBI to authenticate against a database, or working with other schemes like SMB or Radius - see the 25+ Apache::Auth* modules on CPAN for just about anything you could think of. however, we do describe how to use the mod_perl API to interact with Apache the same way mod_auth does using $r-get_basic_auth_pw() and $r-not_basic_auth_failure() in a few different ways. you will also find those two methods in the eagle book if you have it. make sense? --Geoff
Re: Setting require in Authentication handler?
On Mon, 20 May 2002, Geoffrey Young wrote: Todd Chapman wrote: That makes sense. I can't use mod_auth because I can't set Require. well, if you're saying that you don't have the ability to set the Require directive at all (as in you don't have access to edit httpd.conf), then you can't run any authentication handler - mod_auth, mod_perl, or otherwise. Apache core requires the Require directive to be set to something before it will even try to run the authen/authz phases of the request. so, you may be out of luck and need to resort to the CGI tricks of yore where everything is clumped in the content-generation phase (and of which I'm not that familiar). I can set Require, but I will have to ignore it's value since the realm, password file, and require are decided based on the URI. I'm using Basic authentication and text based password files. Unfortunately, I can't find an Apache::Auth* module that handles basic authentication against text files. Did I miss it somewhere? I'm not sure, but it may not exist for the reason I stated eariler about mod_perl not duplicating default Apache behavior. IIRC, there is one that authenticates against /etc/passwd, so maybe you can use that as an example of flat file based processing. in general, though, the steps are pretty much the same no matter which authentication method you choose. see http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm for an example - all you need to do is replace the authenticate_user() subroutine with calls that validate the user based on your own criteria. Thanks. Sounds like we need an Apache::AuthBasicFile since mod_auth doesn't allow Require to be set dynamically. -Todd HTH --Geoff
Re: Setting require in Authentication handler?
Todd Chapman wrote: Can dir_config be used to set 'require' in an authentication handler? no. dir_config() provides access to a mod_perl specific table of variables, not generic Apache configuration directives. there is no API for setting the Require directive - it needs to be in your httpd.conf. I would then return DECLINED do that Apache's Basic auth handler would do the heavy lifting of checking the password. if you're looking to do conditional authentication what you really need to do is a bit backward - turn on all authentication hooks using the Require directive then use your handler to return OK when you don't want Apache to check the password. See recipe 13.5 in the cookbook for more information. the Satisfy any Apache directive may be able to help as well if you're using host-based criteria to determine whether you want to require a login. HTH --Geoff
Re: Setting require in Authentication handler?
Todd Chapman wrote: I need to decide who has access based on the URI. I guess this means I can't use Apache's Basic auth module, since I can't dynamically set require. as I was saying, go ahead and set the Require directive on the Location (or whatever) that you want to protect. if a URI comes in that you want to allow _without_ checking the password just call $r-set_handlers(PerlAuthenHandler = [\OK]); which will essentially short-circuit Apache's default authentication mechanism before mod_auth gets the chance to step in. you could do this from a PerlAccessHandler or (I suppose) a PerlTransHandler. you could probably even just return OK from a PerlAuthenHandler if $r-uri =~ m/some_ok_uri/ and skip the previous code (though if you use something other than Require valid-user you'll have to skip the Authorization phase as well using a similar measure). basically, mod_perl gives you a hook into authentication that lets you do whatever you want - returning OK says that you have validated the user using your own criteria, and mod_auth need not run. returning DECLINED (as you mentioned earlier) allows mod_auth to run. Does the cookbook have a code sample of checking the password for basic authentication? well, not via .htpasswd files, no. in general, it doesn't make much sense to use mod_perl to duplicate the same things that Apache already does for you, since the Apache code is faster, has had more eyeballs looking at it for longer, etc. in that sense you wouldn't want to write your own routine to just check a flat file. where mod_perl really shines wrt authentication is with all the other things Perl does well, such as using DBI to authenticate against a database, or working with other schemes like SMB or Radius - see the 25+ Apache::Auth* modules on CPAN for just about anything you could think of. however, we do describe how to use the mod_perl API to interact with Apache the same way mod_auth does using $r-get_basic_auth_pw() and $r-not_basic_auth_failure() in a few different ways. you will also find those two methods in the eagle book if you have it. make sense? --Geoff
Re: Setting require in Authentication handler?
Todd Chapman wrote: That makes sense. I can't use mod_auth because I can't set Require. well, if you're saying that you don't have the ability to set the Require directive at all (as in you don't have access to edit httpd.conf), then you can't run any authentication handler - mod_auth, mod_perl, or otherwise. Apache core requires the Require directive to be set to something before it will even try to run the authen/authz phases of the request. so, you may be out of luck and need to resort to the CGI tricks of yore where everything is clumped in the content-generation phase (and of which I'm not that familiar). I'm using Basic authentication and text based password files. Unfortunately, I can't find an Apache::Auth* module that handles basic authentication against text files. Did I miss it somewhere? I'm not sure, but it may not exist for the reason I stated eariler about mod_perl not duplicating default Apache behavior. IIRC, there is one that authenticates against /etc/passwd, so maybe you can use that as an example of flat file based processing. in general, though, the steps are pretty much the same no matter which authentication method you choose. see http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm for an example - all you need to do is replace the authenticate_user() subroutine with calls that validate the user based on your own criteria. HTH --Geoff
Re: Setting require in Authentication handler?
A remark: in many cases, the authentication against the password file can be replaced by verifying valid FTP/Telnet login to localhost, not only because the password (shadow) file is usually not avialble for Apache account but also secure. In the ticketing system, the FTP/Telnet authentication runs only at the first time of login and the follow-up access can goes without re-FTP and so is pretty fast. Check this : http://modperl.home.att.net Peter Bi - Original Message - From: Geoffrey Young [EMAIL PROTECTED] To: Todd Chapman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, May 20, 2002 6:50 AM Subject: Re: Setting require in Authentication handler? Todd Chapman wrote: That makes sense. I can't use mod_auth because I can't set Require. well, if you're saying that you don't have the ability to set the Require directive at all (as in you don't have access to edit httpd.conf), then you can't run any authentication handler - mod_auth, mod_perl, or otherwise. Apache core requires the Require directive to be set to something before it will even try to run the authen/authz phases of the request. so, you may be out of luck and need to resort to the CGI tricks of yore where everything is clumped in the content-generation phase (and of which I'm not that familiar). I'm using Basic authentication and text based password files. Unfortunately, I can't find an Apache::Auth* module that handles basic authentication against text files. Did I miss it somewhere? I'm not sure, but it may not exist for the reason I stated eariler about mod_perl not duplicating default Apache behavior. IIRC, there is one that authenticates against /etc/passwd, so maybe you can use that as an example of flat file based processing. in general, though, the steps are pretty much the same no matter which authentication method you choose. see http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm for an example - all you need to do is replace the authenticate_user() subroutine with calls that validate the user based on your own criteria. HTH --Geoff
Setting require in Authentication handler?
Can dir_config be used to set 'require' in an authentication handler? I would then return DECLINED do that Apache's Basic auth handler would do the heavy lifting of checking the password. Thanks! -Todd
mod_perl: User Authentication recommendations requested
I have a requirement to protect all pages on a website, and to only allow in users with a valid user id, password, client certificate and recognised IP. I know this is asking a lot, but I would appreciate an overview/recommendation of approaches that are 1st safe, and 2nd fast. I think something like: Scenario 1: unauthenticated user gets authenticated 1) user hits site - no session = unauthenticated create new session, remember requested page, redirect to /login page 2) /login page: collect username/password, POST action is /authenticate 3) /authenticate page: perform checks, if all ok set $session-is_logged_in(TRUE); and redirect to originally requested page [stored in session] Scenario 2: authenticated user accesses site 1) user hits page - has session redirect to /login if ( not $session-is_logged_in() ); redirect to /login?message=inactivity+timeout if ( time-$session-last_access()1hr ); Which seems to fit the functionality bill - users can bookmark their favourite part of the system. When they come in but have not yet authenticated, they get momentarily diverted through the /login/authenticate pages. Is this safe? How should I ensure that the sessions never get hijacked? I am thinking along the lines of an additional transient cookie issued when the session authenticates the user that contains md5(some_secret+session_id) that is also checked? And... is there already a nifty mod_perl class that does all this? I have Apache::AuthCookie working from examples, but don't know what the security implications of using it are, without reading the code [which I will do soon I guess]. I also have problems with the LOGIN POST saying POST: METHOD NOT ALLOWED when I try to get mod_perl to be the handler for Location /. Any recommendations/feedback appreciated! Even if it's a recipe I haven't yet reached! Thanks in advance, Jeff
RE: mod_perl: User Authentication recommendations requested
And then he reads on p360 that there are tantalising recipes in chapter 13... I would still appreciate the lists thoughts and experience. -Original Message- From: Jeff AA [mailto:[EMAIL PROTECTED]] Sent: 14 May 2002 09:07 To: [EMAIL PROTECTED] Subject: mod_perl: User Authentication recommendations requested I have a requirement to protect all pages on a website, and to only allow in users with a valid user id, password, client certificate and recognised IP. I know this is asking a lot, but I would appreciate an overview/recommendation of approaches that are 1st safe, and 2nd fast. I think something like: Scenario 1: unauthenticated user gets authenticated 1) user hits site - no session = unauthenticated create new session, remember requested page, redirect to /login page 2) /login page: collect username/password, POST action is /authenticate 3) /authenticate page: perform checks, if all ok set $session-is_logged_in(TRUE); and redirect to originally requested page [stored in session] Scenario 2: authenticated user accesses site 1) user hits page - has session redirect to /login if ( not $session-is_logged_in() ); redirect to /login?message=inactivity+timeout if ( time-$session-last_access()1hr ); Which seems to fit the functionality bill - users can bookmark their favourite part of the system. When they come in but have not yet authenticated, they get momentarily diverted through the /login/authenticate pages. Is this safe? How should I ensure that the sessions never get hijacked? I am thinking along the lines of an additional transient cookie issued when the session authenticates the user that contains md5(some_secret+session_id) that is also checked? And... is there already a nifty mod_perl class that does all this? I have Apache::AuthCookie working from examples, but don't know what the security implications of using it are, without reading the code [which I will do soon I guess]. I also have problems with the LOGIN POST saying POST: METHOD NOT ALLOWED when I try to get mod_perl to be the handler for Location /. Any recommendations/feedback appreciated! Even if it's a recipe I haven't yet reached! Thanks in advance, Jeff
problems with authentication handler
Greetings,
I have written a mod_perl authentication module and I am trying to figure
out how to get it to protect top level directories. I have it setup in such
a way that it calls lower level directories to display the login form and
when I protect the top level directory it just loops and gives me the login
screen when i attempt to login. I assume this is because it needs
authentication to send the information to the login handler. I tried to fix
the problem by adding a PerlFixupHandler to a subroutine that returns OK,
which didn't fix the problem.
Here is the httpd.conf entry:
Location /
AuthType Apache::CookieLogin
AuthName TestAuth
PerlAuthenHandler Apache::CookieLogin::authenticate
PerlAuthzHandler Apache::CookieLogin::authorize
require valid-user
/Location
Location /login
AuthType Apache::CookieLogin
AuthName TestAuth
SetHandler perl-script
PerlFixupHandler Apache::CookieLogin::no_auth_req
PerlHandler Apache::CookieLogin::login_handler
/Location
Location /loginform
AuthType Apache::CookieLogin
AuthName TestAuth
SetHandler perl-script
PerlFixupHandler Apache::CookieLogin::no_auth_req
Perlhandler Apache::CookieLogin::login_screen
/Location
Location /logout
AuthType Apache::CookieLogin
AuthName TestAuth
SetHandler perl-script
PerlFixupHandler Apache::CookieLogin::no_auth_req
Perlhandler Apache::CookieLogin::logout
/Location
the no_auth_req subroutine:
sub no_auth_req {
return OK;
}
any ideas would be greatly appreciated.
Thanks,
DJ
Re: mod_perl Basic Authentication problem using PerlAuthenHandler
Thank you... cant believe I missed that... was to excited about the ability to do my own auth program I added allow from x.x.x.x and it worked great Thank you. - Original Message - From: Geoffrey Young [EMAIL PROTECTED] To: Jason [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, April 17, 2002 6:21 PM Subject: Re: mod_perl Basic Authentication problem using PerlAuthenHandler Jason wrote: In httpd.conf i have Location /~jter [snip] Deny from all /Location [snip] It warns to the log file and returns But the problem is, why does my browser come up forbidden I suspect Deny from all is the issue... the PerlAccessHandler will run before the apache default mod_access gets the chance to implement the Deny rule. on a successful login, your PerlAccessHandler will return OK, which is then denied by mod_access, resulting in a FORBIDDEN message. unlike with the PerlAuthenHandler, which immediately terminates on the first OK, the PerlAccessHandler will keep going in search of failure. Has anybody gotten this to sucessfully work? yes :) you may be interested in chapter 13 of the cookbook, which should help clarify things somewhat. --Geoff
mod_perl Basic Authentication problem using PerlAuthenHandler
In httpd.conf i have
Location /~jter
PerlAccessHandler ApacheAuthentication
PerlSetVar Intranet 65.103.229.188 = joe, 10.10.10.2 = userB
PerlAuthenHandler ApacheAuthentication
AuthName realm
AuthType Basic
Require valid-user
Order deny,allow
Deny from all
/Location
And my module is
package ApacheAuthentication;
#use strict;
use Apache::Constants qw(:common);
use Apache::URI;
use Apache::File;
sub handler {
my $r = shift;
# get user's authentication credentials
my ($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
my $user = $r-connection-user;
# authenticate through DBI
my $reason = authen_dbi($r, $user, $sent_pw);
if ($reason) {
$r-note_basic_auth_failure;
$r-log_reason($reason, $r-uri);
return AUTH_REQUIRED;
}
warn FINISHED $user $sent_pw;
return OK;
}
It warns to the log file and returns But the problem is, why does my browser come
up forbidden
Has anybody gotten this to sucessfully work?
Server Version: Apache/1.3.22 (Unix) PHP/4.0.6 mod_perl/1.26 mod_ssl/2.8.5
OpenSSL/0.9.6b
Thanks in advance
Re: Proxy authentication against a mod_perl backend - how?
On Mon, 1 Apr 2002, Fury wrote: I've recently reconfigured a web server to use the front-end proxy/back-end mod_perl configuration. One application runs happily on the mod_perl server, with static content being served from the proxy, and dynamic requests forwarded to the backend. However, I have a request to insert a bunch of static content onto the proxy server, which is fine. As an added requirement, the content is to be protected. Now, I could just use the standard Apache access files, but they're ugly, and get slow as they grow. Ideally, I'd like to use the backend database to hold the user information used for authentication. How can I configure the proxy (which doesn't have mod_perl) to authenticate against the back end? My first thoughts were to use mod_proxy to forward requests for /protected/login to the backend, where the authentication will be done. Then, just redirect the request to another URL behind /protected. The authentication information should be passed as part of the request, should it not? I'd also reverse proxy the URL's - I don't think this would work if I didn't. mod_accel can do such authorization with directive AccelRevalidateUser. Authorization can be done via HTTP Basic authorization or cookie. If directive is active the following happens: 1. if there is no cached response then it request is passed to backend; 2 if backend reponses with 200 code then reponse is cached; 3. if there is cached reponse then request is passed to backend with If-Modified-Since header that set to Last-Modified header of cached reponse; 4. if backend reponses with code 304 or 200 then cached or received reponse send to client; 5. if backend reponses with any other codes then reponse send to client but cached reponse is not deleted. But this feature is usefull only if backend authorization and 304 (Not Modified) generating is cheaper then full reponse (200) generating. Igor Sysoev igor sysoev.ru
Proxy authentication against a mod_perl backend - how?
Subject line says it all. I've recently reconfigured a web server to use the front-end proxy/back-end mod_perl configuration. One application runs happily on the mod_perl server, with static content being served from the proxy, and dynamic requests forwarded to the backend. However, I have a request to insert a bunch of static content onto the proxy server, which is fine. As an added requirement, the content is to be protected. Now, I could just use the standard Apache access files, but they're ugly, and get slow as they grow. Ideally, I'd like to use the backend database to hold the user information used for authentication. How can I configure the proxy (which doesn't have mod_perl) to authenticate against the back end? My first thoughts were to use mod_proxy to forward requests for /protected/login to the backend, where the authentication will be done. Then, just redirect the request to another URL behind /protected. The authentication information should be passed as part of the request, should it not? I'd also reverse proxy the URL's - I don't think this would work if I didn't. Am I on the right track here or not? -klm. --- Kenneth L. Miller, Consultant Shetland Software Services Inc. [EMAIL PROTECTED]
Re: Proxy authentication against a mod_perl backend - how?
My first thoughts were to use mod_proxy to forward requests for /protected/login to the backend, where the authentication will be done. Then, just redirect the request to another URL behind /protected. The authentication information should be passed as part of the request, should it not? Sure, but your proxy server won't be checking to see what it is. People could go to any of your proctected pages freely if they know the URL. Sounds like you're going to a lot of trouble to avoid using standard auth to me. There are a number of auth modules out there which don't need mod_perl, and you may find one that will play nicely with your backend programs. Modules that auth against MySQL or LDAP servers exist. If you're determined to do auth on the backend, I would just let the backend do the auth and serving of the static pages. It will dump them out fast and let the proxy servers do the slow work of dribbling the bytes out to clients. - Perrin
Authentication redirection
I am attempting to redirect certain users during the authentication phase
to support password expiration management. I am not having success
building it directly into the authentication module and think it may be
perhaps that the internal REDIRECT constant is ignored if given outside of
a content handling phase. Could someone confirm this thought? I was
attempting this bit of code:
if ($expired eq 'true') {
$r-content_type('text/html');
$r-header_out(Location = $redirect);
return REDIRECT;
}
The behavior from this bit of code is just as if I had returned OK.
My other idea is to just write a note on the board and have a downstream
content handler do the redirection, but I was hoping to roll it all into
one package, since the problem, password expiration, is most directly tied
to authentication.
Thanks,
Christian
-
Christian Gilmore
Team Lead
Web Infrastructure Tools
IBM Software Group
Re: Authentication redirection
Christian Gilmore wrote: I am attempting to redirect certain users during the authentication phase to support password expiration management. I am not having success building it directly into the authentication module and think it may be perhaps that the internal REDIRECT constant is ignored if given outside of a content handling phase. Could someone confirm this thought? for the resource control phases the proper response is generally AUTH_REQUIRED or FORBIDDEN. AUTH_REQUIRED triggers a special set of headers, so if you're trying to bypass those, instead of using REDIRECT try returning FORBIDDEN with a custom response $r-custom_response(FORBIDDEN, $redirect_url); return FORBIDDEN; HTH --Geoff
Re: Authentication redirection
$r-headers_out-set(Location = /whatever);
$r-status(REDIRECT);
$r-send_http_header;
I belive this will work for you.
END
--
Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118
Science, Discovery, the Universe (UMCP)
Webmaster Webship Teacher
URL: http://www.sdu.umd.edu
EJPress.com
Database/PERL Programmer System Admin
URL : http://www.ejournalpress.com
Resume : http://p6m7g8.com/Work/index.html
On Thu, 7 Mar 2002, Christian Gilmore wrote:
I am attempting to redirect certain users during the authentication phase
to support password expiration management. I am not having success
building it directly into the authentication module and think it may be
perhaps that the internal REDIRECT constant is ignored if given outside of
a content handling phase. Could someone confirm this thought? I was
attempting this bit of code:
if ($expired eq 'true') {
$r-content_type('text/html');
$r-header_out(Location = $redirect);
return REDIRECT;
}
The behavior from this bit of code is just as if I had returned OK.
My other idea is to just write a note on the board and have a downstream
content handler do the redirection, but I was hoping to roll it all into
one package, since the problem, password expiration, is most directly tied
to authentication.
Thanks,
Christian
-
Christian Gilmore
Team Lead
Web Infrastructure Tools
IBM Software Group
LDAP authentication
Hi! I have SunOS 5.8 machine and apache 1.3.22 with mod_perl 1.26 on it. Now I'm trying to install in apache authentication against LDAP server. So I installed AuthenLDAP module. But when I try to go to the directory in browser, apache says - Internal Server Error, and in error.log file I see Undefined subroutine Apache::AuthenLDAP::handler called. OK. I try to investigate the problem and add 'PerlModule Apache::AuthenLDAP' in httpd.conf And now when making 'apachectl configtest' I get this error ': -- Syntax error on line 348 of /usr/local/apache/conf/httpd.conf: Can't load '/usr/local/lib/perl5/5.6.1/sun4-solaris/auto/IO/IO.so' for module IO : ld.so.1: /usr/local/apache/bin/httpd: fatal: relocation error: file /usr/local/lib/perl5/5.6.1/sun4-solaris/auto/IO/IO.so: symbol main: referenced symbol not found at /usr/local/lib/perl5/5.6.1/sun4-solaris/XSLoader.pm line 75. at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO.pm line 9 Compilation failed in require at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Handle.pm line 256. BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Handle.pm line 256. Compilation failed in require at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Socket.pm line 11. BEGIN failed--compilation aborted at /usr/local/lib/perl5/5.6.1/sun4-solaris/IO/Socket.pm line 11. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.6.1/Net/LDAP.pm line 8. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.6.1/Net/LDAP.pm line 8. Compilation failed in require at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenLDAP.pm line 269. BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/5.6.1/Apache/AuthenLDAP.pm line 269. Compilation failed in require at (eval 3) line 3. -- What may be the problem in? -- Andrew.
RE: Multiple authentication methods
At 17:21 13.02.2002 -0600, you wrote:
File::Spec is in included with the standard perl mods I believe
so dependencies shouldn't be a problem.
I see. You're right, this is actually much nicer!
Sorry for the misinformation. On debian it return : also. I made a
mistake checking it.
But with the suggested code by Per it works just fine:
sub load {
my $module=@_[0];
$module = File::Spec-catfile(split /::/, $module);
$module .= '.pm';
eval { require $module; };
return $@ ? 1 : 0;
}
Of course one has to put a use File::Spec at the beginning and a Per
Finar Ellefsen
That's Per Einar :)
I think this module is a great idea. You should get it on CPAN as soon as
possible.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Multiple authentication methods
Hi Darren Would you submit the current version? If you need help with the Documentation just let me know. For the makefile, I do not have any experience. Marcel Am Mittwoch den, 13. Februar 2002, um 21:01, schrieb darren chamberlain: Quoting Marcel Weber [EMAIL PROTECTED] [13 Feb-02 14:53]: Why not submitting this somewhere? I think this could be usefull for quite a lot of people. I think this is cool, as you do not have to worry wether the module returns DECLINED or AUTH_REQUIRED. I can package this up and put it on CPAN as version 0.01 tomorrow morning, if that seems reasonable to everyone involved. I'll need to add some docs and a Makefile.PL, of course. (darren) -- To believe is very dull. To doubt is intensely engrossing. To be on alert is to live, to be lulled into security is to die. -- Oscar Wilde --- PGP / GPG Key: http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc
Re: Multiple authentication methods
Quoting Marcel Weber [EMAIL PROTECTED] [12 Feb-02 16:15]:
I don't get the point why it did not work the other way round,
but now everything is just fine now :
Make it a little more generic:
package Apache::MultiAuthen;
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
# Tweak this; unsure about dir_config returning an array
my @auth_modules = $r-dir_config(AuthModules);
for my $am (@auth_modules) {
load($am);
if ($@) {
$r-log(Error loading module '$am': $@);
next;
}
my $handler = \{$am\::handler};
if ($handler-($r) == OK) {
$r-log_reason($am return OK);
return OK
}
$r-log_reason($am not OK);
}
$r-note_basic_auth_failure;
return AUTH_REQUIRED;
}
sub load {
my $module = @_;
$module =~ s[::][/]g;
$module .= '.pm';
eval { require $module; };
return $@ ? 1 : 0;
}
1;
__END__
(darren)
--
Never attribute to malice that which is adequately explained by
incompetence.
-- Napolean Bonaparte
Re: Multiple authentication methods
shouldn't stacked handlers be the right solution here? are stacked auth
handlers not allowed or something?
aaron
On Wed, 2002-02-13 at 09:02, darren chamberlain wrote:
Quoting Marcel Weber [EMAIL PROTECTED] [12 Feb-02 16:15]:
I don't get the point why it did not work the other way round,
but now everything is just fine now :
Make it a little more generic:
package Apache::MultiAuthen;
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
# Tweak this; unsure about dir_config returning an array
my @auth_modules = $r-dir_config(AuthModules);
for my $am (@auth_modules) {
load($am);
if ($@) {
$r-log(Error loading module '$am': $@);
next;
}
my $handler = \{$am\::handler};
if ($handler-($r) == OK) {
$r-log_reason($am return OK);
return OK
}
$r-log_reason($am not OK);
}
$r-note_basic_auth_failure;
return AUTH_REQUIRED;
}
sub load {
my $module = @_;
$module =~ s[::][/]g;
$module .= '.pm';
eval { require $module; };
return $@ ? 1 : 0;
}
1;
__END__
(darren)
--
Never attribute to malice that which is adequately explained by
incompetence.
-- Napolean Bonaparte
--
aaron ross . alias intelligence, inc
email . [EMAIL PROTECTED]
phone . 215 545 6428
Re: Multiple authentication methods
Quoting Aaron Ross [EMAIL PROTECTED] [13 Feb-02 09:21]: shouldn't stacked handlers be the right solution here? are stacked auth handlers not allowed or something? Assuming your mod_perl has been built with them, then, yes, that's probably a better solution. But I had a fun 15 minutes writing Apache::MultiAuthen, though. :) (darren) -- My studies in Speculative Philosophy, metaphysics, and science are all summed up in the image of a mouse called man running in and out of every hole in the Cosmos hunting for the Absolute Cheese. -- Edmund Burke
RE: Multiple authentication methods
He wants to check a 'handler' return value.
shouldn't stacked handlers be the right solution here? are stacked auth
handlers not allowed or something?
aaron
On Wed, 2002-02-13 at 09:02, darren chamberlain wrote:
Quoting Marcel Weber [EMAIL PROTECTED] [12 Feb-02 16:15]:
I don't get the point why it did not work the other way round,
but now everything is just fine now :
Make it a little more generic:
package Apache::MultiAuthen;
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
# Tweak this; unsure about dir_config returning an array
my @auth_modules = $r-dir_config(AuthModules);
for my $am (@auth_modules) {
load($am);
if ($@) {
$r-log(Error loading module '$am': $@);
next;
}
my $handler = \{$am\::handler};
if ($handler-($r) == OK) {
$r-log_reason($am return OK);
return OK
}
$r-log_reason($am not OK);
}
$r-note_basic_auth_failure;
return AUTH_REQUIRED;
}
sub load {
my $module = @_;
$module =~ s[::][/]g;
$module .= '.pm';
eval { require $module; };
return $@ ? 1 : 0;
}
1;
__END__
(darren)
--
Never attribute to malice that which is adequately explained by
incompetence.
-- Napolean Bonaparte
--
aaron ross . alias intelligence, inc
email . [EMAIL PROTECTED]
phone . 215 545 6428
Re: Multiple authentication methods
Aaron Ross wrote: shouldn't stacked handlers be the right solution here? are stacked auth handlers not allowed or something? yes, you can stack multiple auth handlers. the only problem is that, for the PerlAuthenHandler and PerlAuthzHandler the first handler to return an Apache error code (anything other than OK, DECLINED, or DONE) terminates the chain. which is generally fine, except when you want to return AUTH_REQUIRED and note_basic_auth_failure(). when writing your own auth modules, you could return DECLINED (and not call note_basic_auth_failure()) instead of AUTH_REQUIRED and let mod_auth take care of setting AUTH_REQUIRED for you (since the perl handlers generally run before the Apache C modules). however, with Apache::AuthFoo, the AUTH_REQUIRED stuff is generally compiled in, which means that the authentication chain is terminated prematurely. the solution darren posted is kinda nifty and is along the lines of what you would need to have in order to use the shrink-wrapped Apache:: solutions - one controlling handler that traps the return code of the other handlers, keeping them from Apache so that Apache doesn't end the handler chain before you're ready. HTH --Geoff
Re: Multiple authentication methods
the only problem is that, for the PerlAuthenHandler and PerlAuthzHandler the first handler to return an Apache error code (anything other than OK, DECLINED, or DONE) terminates the chain. which is generally fine, except when you want to return AUTH_REQUIRED and note_basic_auth_failure(). blarg... of course, returning OK also ends the chain, meaning that the user has been authenticated and Apache can stop now. in that respect both the PerlAuthenHandler and PerlAuthzHandler are like the PerlTransHandler (if that helps you think about it). sorry, too much information up there :) --Geoff
