mp2: session/auth handlers stable enough to use?

[Carl Brewer]

I'm looking at Apache::SessionX from Embperl as a possible
session tracker for an app I'm doing with Template::Toolkit,
has anyone any comments/suggestions re how mature this,
(or any other recommendations?) session tracking module
is under mp2?  I've read some comments on CPAN discussing
the use of tie() and performance, which I confess to
knowing nothing about.  Is any of this relevant to
mp2?  I want to avoid 100% any use of the compat stuff in
mp2, and make this as pure an mp2 site as possible.
thanks :)

Carl

Re: [mp2] Cookie behavior discrepancy in Auth* handlers ?

[Nick Tonkin]

On Wed, 19 Feb 2003, Nick Tonkin wrote:


 Hi all,

 Cookies driving me nuts as usual but I think the problem appears to be
 related to which handler phase we are in.

 Basically, the same call to read the cookies works in the PerlHandler but
 not in the PerlAccessHandler.

Responding to my own post here, to keep the archive complete. (That's the
only reason, since there doesn;t seem to be anyone else using cookies for
auth stuff in mp2 ...)

Testing has shown that the first diagnosis was correct. Stas tracked it
down to %ENV not getting populated prior to the Response phase. He is
working on a fix.

Meanwhile I'm getting around the problem by subclassing CGI::Cookie (which
we are using since Apache::Request is not ported to mp2 yet) thusly:

package WM::Auth::Cookie;

use strict;
use warnings;
use CGI::Cookie;

WM::Auth::Cookie::ISA = qw/CGI::Cookie/;

sub fetch {
my $class = shift;
my $r = shift;
my $raw_cookie = $r-headers_in-{'Cookie'};
return () unless $raw_cookie;
return $class-parse($raw_cookie);
}

1;

the only difference in API being that one must replace

my $cookie = CGI::Cookie-fetch();

with

my $cookie = WM::Auth::Cookie-fetch($r);

Looking forward to the proper fix though.


- nick

-- 


Nick Tonkin   {|8^)

[mp2] Cookie behavior discrepancy in Auth* handlers ?

[Nick Tonkin]

Hi all,

Cookies driving me nuts as usual but I think the problem appears to be
related to which handler phase we are in.

Basically, the same call to read the cookies works in the PerlHandler but
not in the PerlAccessHandler.

in Access.pm I have :

use CGI;
use CGI::Cookie;
sub handler {
my $r = shift;
warn $r-as_string;
my $cookies = fetch CGI::Cookie;
warn Access Dumping Cookies:\n . Dumper($cookies);
return Apache::DECLINED if $r-uri =~ m|/authenticate|

Access.pm is called thus:

Location /
AddType text/html .html
AddHandler server-parsed .html
Options +Includes

PerlSetVar  WM_Auth_Domain wm.tonkinresolutions.com
PerlAccessHandler   WM::Auth::Access
/Location

in Auth.pm I have :

use CGI;
use CGI::Cookie;
sub handler {
my $r = shift;
warn $r-as_string;
my $cookies = fetch CGI::Cookie;
warn Auth Dumping Cookies:\n . Dumper($cookies);

Auth.pm is called thus:

ErrorDocument 403 /authenticate

Location /authenticate
sethandler perl-script
PerlHandler WM::Auth::Auth
/Location

I request /authenticate when I already have an 'auth' cookie on the
browser, and I get this:

Access Dumping Headers:
GET /authenticate?foo HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: wm.tonkinresolutions.com
Connection: Keep-Alive
Cookie: foo=bar;
remembered_uri=https%3A%2F%2Fwm.tonkinresolutions.com%2Findex.html;
auth=hash6032ccbfd909f951dcfbd804441163bcgroup_namerootsession580a5fc6a0215f2eaecde2e6d5554b07usernick_time1045689878expires60

INCLUDED (null)

Access Dumping Cookies:
$VAR1 = undef;

Auth Dumping Headers:
GET /authenticate?foo HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: wm.tonkinresolutions.com
Connection: Keep-Alive
Cookie: foo=bar;
remembered_uri=https%3A%2F%2Fwm.tonkinresolutions.com%2Findex.html;
auth=hash6032ccbfd909f951dcfbd804441163bcgroup_namerootsession580a5fc6a0215f2eaecde2e6d5554b07usernick_time1045689878expires60

HTTP/1.1 (null)

Auth Dumping Cookies:
$VAR1 = {
  'auth' = bless( {
 'value' = [
  'hash',
  '6032ccbfd909f951dcfbd804441163bc',
  'group_name',
  'root',
  'session',
  '580a5fc6a0215f2eaecde2e6d5554b07',
  'user',
  'nick',
  '_time',
  '1045689878',
  'expires',
  '60'
],
 'name' = 'auth',
 'path' = '/'
   }, 'CGI::Cookie' ),
  'foo' = bless( {
'value' = [
 'bar'
   ],
'name' = 'foo',
'path' = '/'
  }, 'CGI::Cookie' ),
  'remembered_uri' = bless( {
   'value' = [

'https://wm.tonkinresolutions.com/index.html'
  ],
   'name' = 'remembered_uri',
   'path' = '/'
 }, 'CGI::Cookie' )
};



Can anyone offer a clue?

Thanks,

- nick

-- 


Nick Tonkin   {|8^)

RE: Auth Handlers

[Stathy Touloumis]

He he : )  I think this discussion is being miscommunicated (if that is a
relevant word).  I do not want authorization to be performed in the typical
manner.  Perhaps I want the information from a form submit or a cookie.  I
understand how the Apache authentication configuration works but I want to
strictly use mod_perl to modify the authentication mechanisms without the
standard Apache intervention.

 You mean you want to do authorization in a FixupHandler??
No, this is what I currently have to do to avoid Apache from sending the
'auth request' headers to the browser and still perform custom
authentication via a form submit, cookie, etc.

Thanks,

  : )  No problem,  I guess I am unsure if this is the proper way
 to setup an
  Access, Authen, Authz handler.  When I use this configuration
 my 'handler()'
  method does not get called and I get an error in the logs:
  [Mon Dec 10 13:13:03 2001] [crit] [client 192.168.0.1]
 configuration error:
  couldn't check user.  No user file?: /index.html

 I think Apache is looking for the wrong file.  Check the config
 for AuthUserFile.
 Did you use htpasswd to create it?

  I tried moving it down to be an Authz handler but the same error occurs.
  However, if I push this package as a FixupHandler it works fine and the
  'handler()' method gets called.

 You mean you want to do authorization in a FixupHandler??

 If you like I can let you have some scripts which will show you one way of
 checking for authorization without a second request for a
 username/password,
 assuming that at some stage in the browser session one was
 already supplied.
 Is that what you meant?

 73,
 Ged.

RE: Auth Handlers

[Eric Cholet]

--On mardi 11 décembre 2001 23:36 +0100 J. Zobel 
[EMAIL PROTECTED] wrote:

 On Tue, 2001-12-11 at 21:00, Stathy Touloumis wrote:
 Actually, I DON'T want the browser to prompt for a username/pass.  I saw
 the examples in the eagle book and they all seem to use Authz, with Auth
 handlers using the example you showed.
 Perhaps I need to modify the headers so that the prompt does not occur?

 I have the exact same problem. I want my AuthenHandler to decide if the
 user is prompted for a password. Unfortunately the book tells me:

 By the time the handler is called, Apache will have done most of the
 work in negotiating the HTTP Basic authentication protocol. It will have
 alerted the browser that authentication is required to access the page,
 and the browser will have prompted the user to enter his name and
 password.

 Has anybody got an idea how to let a handler decide, if autthen. is
 required?

You could use a PerlAccessHandler, if you figure authentication isn't 
required
you run
   $r-set_handlers(PerlAuthenHandler = [\OK]);

--
Eric Cholet

RE: Auth Handlers

[Stathy Touloumis]

What I have down is moved out specific auth handler down the chain into the
'fixup' state but it would be much nicer (and ituitive) to place it in the
appropriate position.

 On Tue, 2001-12-11 at 21:00, Stathy Touloumis wrote:
  Actually, I DON'T want the browser to prompt for a
 username/pass.  I saw the
  examples in the eagle book and they all seem to use Authz, with Auth
  handlers using the example you showed.
  Perhaps I need to modify the headers so that the prompt does not occur?

 I have the exact same problem. I want my AuthenHandler to decide if the
 user is prompted for a password. Unfortunately the book tells me:

 By the time the handler is called, Apache will have done most of the
 work in negotiating the HTTP Basic authentication protocol. It will have
 alerted the browser that authentication is required to access the page,
 and the browser will have prompted the user to enter his name and
 password.

 Has anybody got an idea how to let a handler decide, if autthen. is
 required?

RE: Auth Handlers

[Stathy Touloumis]

Right, this is fairly obvious but we are trying to prevent apache from
sending the 'login' headers if successful authorization does not occur.  It
seems to me that to do this the handler will need to be moved up or down the
chain which can be unintuitive.

Thanks,

  Has anybody got an idea how to let a handler decide, if autthen. is
  required?

 You can do this via an access handler. For example, we use the access
 handler to see if the user is coming in from a trusted ip address. If they
 are then they are authorized to use the site. Otherwise, the user must
 login.

 The module looks like

 package TrustedAuth;

 ...

 sub access_handler {
 my $r = shift;

 if ( ... ) {
 # Have a trusted host so don't ask user to login
 $r-set_handlers( PerlAuthenHandler = [ \OK ] );
 }
 return OK;
 }

 sub authen_handler {
 # normal stuff here
 }

 1;

 and my httpd.conf has

 PerlModule TrustedAuth

 Location /secure
 AuthName Secure
 AuthType basic
 Require valid-user

 PerlAccessHandler TrustedAuth::access_handler
 PerlAuthenHandler TrustedAuth::authen_handler
 /Location

 ---
 Andrew Gilmartin
 Senior Developer
 Ingenta
 [EMAIL PROTECTED]
 andrewgilmartin (aim)
 401-743-3713 (cell)

RE: Auth Handlers

[lembark]

-- Stathy Touloumis [EMAIL PROTECTED] on 12/12/01 10:31:37 -0600

 Right, this is fairly obvious but we are trying to prevent apache from
 sending the 'login' headers if successful authorization does not occur.  It
 seems to me that to do this the handler will need to be moved up or down the
 chain which can be unintuitive.

Other approach is to use a separate login site and 
redirect people there if they don't meet the auth.
criteria to begin with. This way you don't have to send
AUTH_REQUIRED, just a redirect (or internal redirect).


--
Steven Lembark  2930 W. Palmer
Workhorse Computing  Chicago, IL 60647
   +1 800 762 1582

RE: Auth Handlers

[Stathy Touloumis]

: )  No problem,  I guess I am unsure if this is the proper way to setup an
Access, Authen, Authz handler.  When I use this configuration my 'handler()'
method does not get called and I get an error in the logs:
[Mon Dec 10 13:13:03 2001] [crit] [client 192.168.0.1] configuration error:
couldn't check user.  No user file?: /index.html

I tried moving it down to be an Authz handler but the same error occurs.
However, if I push this package as a FixupHandler it works fine and the
'handler()' method gets called.

Thanks,

 -Original Message-
 From: Ged Haywood [mailto:[EMAIL PROTECTED]]
 Sent: Monday, December 10, 2001 7:16 PM
 To: Stathy Touloumis
 Cc: mod_perl List
 Subject: RE: Auth Handlers


 On Mon, 10 Dec 2001, Stathy Touloumis wrote:

  Directory /home/stathy/apache/html
  AuthName Login
  AuthType Base::Session::Handler
  require valid-user
 
  PerlAuthenHandler Base::Session::Handler
  /Directory

 Forgive me, it's late, and I'm afraid I've deleted the original
 question.  But there isn't much here to go on...

 73,
 Ged.

RE: Auth Handlers

[Rob Bloodgood]

 : )  No problem,  I guess I am unsure if this is the proper way
 to setup an
 Access, Authen, Authz handler.  When I use this configuration my
 'handler()'
 method does not get called and I get an error in the logs:

This is *not* the correct way to invoke it.

   Directory /home/stathy/apache/html
   AuthName Login

# This is incorrect
#  AuthType Base::Session::Handler

# *This* is what you need if you want the
# browser to prompt for a username/pass
AuthType Basic
   require valid-user
  
   PerlAuthenHandler Base::Session::Handler
   /Directory


I just checked my answers from the Eagle (Writing Apache Modules with Perl
and C), and that's the correct way.  If I'm not mistaken, the chapter on
Authentication is one of the sample chapters that's online at
http://www.modperl.com.  Have a look over there, it'll straighten you right
out. :-)

L8r,
Rob

#!/usr/bin/perl -w
use Disclaimer qw/:standard/;

RE: Auth Handlers

[Stathy Touloumis]

Actually, I DON'T want the browser to prompt for a username/pass.  I saw the
examples in the eagle book and they all seem to use Authz, with Auth
handlers using the example you showed.
Perhaps I need to modify the headers so that the prompt does not occur?

Thanks for the info,

 -Original Message-
 From: Rob Bloodgood [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, December 11, 2001 12:54 PM
 To: Stathy Touloumis
 Cc: mod_perl
 Subject: RE: Auth Handlers


  : )  No problem,  I guess I am unsure if this is the proper way
  to setup an
  Access, Authen, Authz handler.  When I use this configuration my
  'handler()'
  method does not get called and I get an error in the logs:

 This is *not* the correct way to invoke it.

Directory /home/stathy/apache/html
AuthName Login

 # This is incorrect
 #  AuthType Base::Session::Handler

 # *This* is what you need if you want the
 # browser to prompt for a username/pass
   AuthType Basic
require valid-user
   
PerlAuthenHandler Base::Session::Handler
/Directory


 I just checked my answers from the Eagle (Writing Apache Modules with Perl
 and C), and that's the correct way.  If I'm not mistaken, the chapter on
 Authentication is one of the sample chapters that's online at
 http://www.modperl.com.  Have a look over there, it'll straighten
 you right
 out. :-)

 L8r,
 Rob

 #!/usr/bin/perl -w
 use Disclaimer qw/:standard/;

RE: Auth Handlers

[J. Zobel]

On Tue, 2001-12-11 at 21:00, Stathy Touloumis wrote:
 Actually, I DON'T want the browser to prompt for a username/pass.  I saw the
 examples in the eagle book and they all seem to use Authz, with Auth
 handlers using the example you showed.
 Perhaps I need to modify the headers so that the prompt does not occur?

I have the exact same problem. I want my AuthenHandler to decide if the
user is prompted for a password. Unfortunately the book tells me:

By the time the handler is called, Apache will have done most of the
work in negotiating the HTTP Basic authentication protocol. It will have
alerted the browser that authentication is required to access the page,
and the browser will have prompted the user to enter his name and
password. 

Has anybody got an idea how to let a handler decide, if autthen. is
required?

Thanx,
Joachim 

 
  # *This* is what you need if you want the
  # browser to prompt for a username/pass
  AuthType Basic
 require valid-user

 PerlAuthenHandler Base::Session::Handler
 /Directory

Auth Handlers

[Stathy Touloumis]

I seem to be unable to get my authentication/authorization handler to be
called correctly.  I have tried numerous directives and it seems to always
get passed to the standard apache 'authentication' module.  I receive this
error :
[Mon Dec 10 13:09:35 2001] [crit] [client 192.168.6.59] configuration error:
couldn't check user.  No user file?: /index.html

OR

the package handler does not get called at all.

Thanks,

Re: Auth Handlers

[Ged Haywood]

Hi there,

On Mon, 10 Dec 2001, Stathy Touloumis wrote:

 error :
 [Mon Dec 10 13:09:35 2001] [crit] [client 192.168.6.59] configuration error:
 couldn't check user.  No user file?: /index.html

Send the config?

73,
Ged.

RE: Auth Handlers

[Stathy Touloumis]

Directory /home/stathy/apache/html
AuthName Login
AuthType Base::Session::Handler
require valid-user

PerlAuthenHandler Base::Session::Handler
/Directory

 Send the config?
 

RE: Auth Handlers

[Ged Haywood]

On Mon, 10 Dec 2001, Stathy Touloumis wrote:

 Directory /home/stathy/apache/html
 AuthName Login
 AuthType Base::Session::Handler
 require valid-user
 
 PerlAuthenHandler Base::Session::Handler
 /Directory

Forgive me, it's late, and I'm afraid I've deleted the original
question.  But there isn't much here to go on...

73,
Ged.