AuthSession Manager [was] Apache::AuthCookie not set cookie really

2002-01-28 Thread BeerBong

 Hello all!

 Odd thing - all should works fine.
 I use Apache::AuthCookie for my project Agenda.
 I wrote descendant - Apache::AuthCookieAgenda
 
 package Apache::AuthCookieAgenda;

 use strict;
 use Apache;
 use Apache::Constants qw(:common);
 use Apache::AuthCookie;
 use Agenda;

 use vars qw($VERSION @ISA);

 $VERSION = substr(q$Revision: 1.1 $, 10);
 @ISA = qw(Apache::AuthCookie);

 sub authen_cred ($$\@) {
 my $self = shift;
 my $r = shift;
 my @creds = @_;

 # This would really authenticate the credentials
 # and return the session key.
 # Here I'm just using setting the session
 # key to the credentials and delaying authentication.
 #
 # Similar to HTTP Basic Authentication, only not base 64 encoded

 join(:, @creds);
 }

 sub authen_ses_key ($$$) {
 my $self = shift;
 my $r = shift;
 my($user, $password) = split(/:/, shift, 2);

 my $modeller = Agenda-new();
 $r-warn(Auth - $user - $password);

 # Authenticate use here...
 $modeller-authorize($user, $password) eq OK ? $user : undef;

 }
 
 In conf file
 
IfDefine power
 Perl
  use lib qw(/usr/web/inc /usr/web/dev.webzavod.ru/modules);
  use Apache::Agenda;
  use Apache::AuthCookieAgenda;
 /Perl
 PerlInitHandler Apache::Reload
 PerlSetVar AuthCookieDebug 10

 Location  /agenda/
   SetHandler perl-script
   PerlHandler Apache::Agenda

   PerlSetVar AgendaPath /agenda
   PerlSetVar AgendaTemplate default.inc
   PerlSetVar AgendaSessionDir /tmp
   PerlSetVar AgendaLoginScript /agenda/login/

   AuthType Apache::AuthCookieAgenda
   AuthName Agenda
   PerlAuthenHandler Apache::AuthCookieAgenda-authenticate
   PerlAuthzHandler Apache::AuthCookieAgenda-authorize
   require valid-user

 /Location
 Location /LOGIN/
   AuthType Apache::AuthCookieAgenda
   AuthName Agenda
   SetHandler perl-script
   PerlHandler Apache::AuthCookieAgenda-login
 /Location

/IfDefine
 
 when I'm trying to access /agenda/ files I get login page, but after
 submit a form, I return to login page again.
 In logs
 

 [Mon Jan 28 12:38:35 2002] [error] credential_0 asdasd
 [Mon Jan 28 12:38:35 2002] [error] credential_1 asdasd
 [Mon Jan 28 12:38:35 2002] [error] ses_key asdasd:asdasd

 OUT Headers goes here

 $VAR1 = 'Pragma';
 $VAR2 = 'no-cache';
 $VAR3 = 'Cache-control';
 $VAR4 = 'no-cache';
 $VAR5 = 'Location';
 $VAR6 = '/agenda/tasks/';

 Error OUT Headers goes here

 $VAR1 = 'Set-Cookie';
 $VAR2 = 'Apache::AuthCookieAgenda_Agenda=asdasd:asdasd';
 $VAR3 = 'Pragma';
 $VAR4 = 'no-cache';

 Redirecting...
 and next phase

 [Mon Jan 28 12:38:35 2002] [error] auth_type
Apache::AuthCookieAgenda
 [Mon Jan 28 12:38:35 2002] [error] auth_name Agenda
 [Mon Jan 28 12:38:35 2002] [error] ses_key_cookie

 Cookie field is empty here - I don't know why...
 Cookie is set via error headers, I know that it is correct for
 REDIRECT responses...
 ses_key_cookie is empty, therefore authen_ses_key not even
requested,
 redirecting to login form again.

 [Mon Jan 28 12:38:35 2002] [error] uri /agenda/tasks/
 [Mon Jan 28 12:38:35 2002] [error] auth_type
Apache::AuthCookieAgenda
 [Mon Jan 28 12:38:35 2002] [warn] Header Dump:
 GET /agenda/tasks/ HTTP/1.0
 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
 application/vnd.ms-excel, application/vnd.ms-powerpoint,
 application/ms
 word, */*
 Accept-Encoding: gzip, deflate
 Accept-Language: ru
 Cache-Control: no-cache
 Cookie: SESSION_ID=1000_56535df97f6ed52c

 I used Apache::Session::Counted, and know that this two modules may
 conflict, but when all Apache::Session::Counted staff is commented
 result is the same...

 Host: warzavod:81
 Referer: http://warzavod/agenda/tasks/
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
 Q312461)
 X-Real-IP: 195.209.67.7

 I dont know why cookie is not set.

 Is there anywhere comparison table for
 Apache::AuthCookie - Apache::AuthTicket
 and table for
 Apache::Session modules - I use Apache::Session::Counted as the
single
 not-database solution wich I found for maintaining state with
cleanup
 feature. Or is there anywhere cleanup example for Apache::Session -
I
 didn't find... Apache::Session::Lock::File-clean cleans up only
lock
 files...
 Apache::ASP - has a good session state algorithm with cleanup...

Ok.
I readed the previous discuss with
http://marc.theaimsgroup.com/?t=10110064594r=1w=2
And ask the question in more general form.

Our team writing project management open source system Agenda.
There is a couple groupware application written on php, I installed
every of them.
All of them cannot be used for
1. Company with greater than 1 department
2. With one or more 

Re: AuthSession Manager [was] Apache::AuthCookie not set cookie really

2002-01-28 Thread Perrin Harkins

 Application's main goals
 1. Simple install.
 I don't want use cron jobs for cleanup - I think, it can be problem
 for some users.

Most of the existing session stuff is written to leave cleanup to you.  If
you don't want to use cron jobs, you can do it in a cleanup handler,
possibly exec'ing a separate script to avoid keeping the heavy mod_perl
process around.

 I need to authorize user and don't want to query on every request is
 you admin, which departments you belong to etc..

Unless you're willing to put real information in the cookie (not just an
ID), you have to do some kind of lookup on the server-side for every request
if they need session information.  It may not be to a database though.  If
you know that each user will stay on a single server, you can use a
disk-based technique like Cache::FileCache or Apache::Session::File.

 Apache::AuthCookie doesn't want to set cookie on redirect (see above).

There's a lot of stuff in the archives about cookies and redirects.  Maybe
that will help.  You're not the first person to have problems with this.

 I don't think that it is good to use the Oracle database for
 maintaining state or secrets for tickets. It can be slower than query
 indexed table even on every request for password and departments where
 user works.

It's generally fast enough, since it's a single row retrieved by ID.  MySQL
is very fast at this kind of thing though.

- Perrin