WE: Apache::AuthCookie causing strange-"Use of uninitialized value."
It is a warning Perl gives on strict, if variables have 0 values or are NULL. The example below will trigger that warning: ### #!/usr/sbin/perl -w use strict; Xyz (fist_value, second_value); # Here we call sub xyz with 2 arguments Sub xyz { my ($x,$y,$z)@_; print $x; print $y; print $z; # This will trigger the warning, because $z has no value. } To arrest the warning, I may use something like this: Print $z if $z; ### -Ursprüngliche Nachricht- Von: Per Eric Rosén [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 12. September 2003 13:46 An: [EMAIL PROTECTED] Betreff: Apache::AuthCookie causing strange-"Use of uninitialized value." I use Apache::AuthCookie 3.04, which seems to be the latest version, under Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian GNU/Linux PHP/4.1.2 mod_perl/1.26. When I use "PerlFixupHandler Apache::AuthCookie->recognize_user", Apache writes "Use of uninitialized value." in errorlog for each request and subrequest. I have tried editing AuthCookie.pm, checking everything with defined(), even substituting recognize_user with a stub function. Still it is there. I am not sure it comes from perl, because perl use to say "at line X" too. But from what else? This has been up before, but no one answered it then: http://www.jsw4.net/info/list-archives/mod_perl/02-08/msg00591.html /Per Eric -- ^): Per Eric Rosén http://rosnix.nu/~per/ / [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
Re: Apache::AuthCookie causing strange "Use of uninitialized value."
Thanks for your response! > You have to subclass Apache::AuthCookie. This should be something like: > PerlFixupHandler Your::Sublass->recognize_user Well, I do. I just pasted the wrong text (from the 2002 mail). The actual configuration snippet is: AuthType TAS::Cookie AuthName TAS PerlFixupHandler TAS::Cookie->recognize_user Another observation: It does only appear when no cookie is received. When users are logged in, everything is fine. And, yes, I checked recognize_user and put in a defined() around the cookie check. No result. Even a bad cookie (manually deleting the session) makes it quiet. /Per Eric -- ^): Per Eric Rosén http://rosnix.nu/~per/ / [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
Re: Apache::AuthCookie causing strange-"Use of uninitialized value."
Hi! On Fri, Sep 12, 2003 at 01:46:24PM +0200, Per Eric Ros?n wrote: > I use Apache::AuthCookie 3.04, which seems to be the latest version, under > Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian GNU/Linux PHP/4.1.2 mod_perl/1.26. I'm using quite the same setup (without PHP and ssl) and do not get those errors. > When I use "PerlFixupHandler Apache::AuthCookie->recognize_user", Apache You have to subclass Apache::AuthCookie. This should be something like: PerlFixupHandler Your::Sublass->recognize_user Maybe this is causing the problem? -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Apache::AuthCookie causing strange-"Use of uninitialized value."
I use Apache::AuthCookie 3.04, which seems to be the latest version, under Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian GNU/Linux PHP/4.1.2 mod_perl/1.26. When I use "PerlFixupHandler Apache::AuthCookie->recognize_user", Apache writes "Use of uninitialized value." in errorlog for each request and subrequest. I have tried editing AuthCookie.pm, checking everything with defined(), even substituting recognize_user with a stub function. Still it is there. I am not sure it comes from perl, because perl use to say "at line X" too. But from what else? This has been up before, but no one answered it then: http://www.jsw4.net/info/list-archives/mod_perl/02-08/msg00591.html /Per Eric -- ^): Per Eric Rosén http://rosnix.nu/~per/ / [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
Apache::AuthCookie 3.05 prerelease
I have placed a pre-release of Apache::AuthCookie 3.05 which supports mod_perl version 2 (as well as mod_perl version 1) up on the sorceforge downloads. The API has changed slightly for mod_perl version 2 in order to avoid using Apache->request. See the README.modperl2 file in the distribution for the detailed changes. The API has not changed in the version of the module for mod_perl 1.x. Obviously since the API has changed, and because this is the first release supporting mod_perl v2, this is an alpha release. This release is targeted at developers of AuthCookie subclasses that wish to port their subclasses to mod_perl2. If I do not get complaints about the AuthCookie API changes that I have made, I will upload this release to CPAN. You can get AuthCookie 3.05pre1 from: https://sourceforge.net/project/showfiles.php?group_id=12701 Regards, Michael Schout GKG.NET, INC
Re: Installing Apache::AuthCookie
I installed it anyway. It seems to be working. I can still send you the httpd.conf if you'd still like jay - Original Message - From: "Michael Schout" <[EMAIL PROTECTED]> To: "Jay Strauss" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, June 11, 2003 11:26 AM Subject: Re: Installing Apache::AuthCookie > On Tue, 10 Jun 2003, Jay Strauss wrote: > > > I'm running into a problem during the make test while installing the current > > version of Apache::AuthCookie. I'm not sure where to go. I looked at tests > > 10 and 15: > > Hrm. You are supposed to get "ok" for all of the tests. > > If I had to guess from this I would say that there is something in your > httpd.conf (that Apache::test is pulling the config from) that is > screwing up the tests. Can you send me your t/httpd.conf? (privately, > no need to send it to the list). > > Regards > Michael > -- > Hal 9000 - "Put down those Windows disks Dave Dave? DAVE!!" > > >
Re: Installing Apache::AuthCookie
On Tue, 10 Jun 2003, Jay Strauss wrote: > I'm running into a problem during the make test while installing the current > version of Apache::AuthCookie. I'm not sure where to go. I looked at tests > 10 and 15: Hrm. You are supposed to get "ok" for all of the tests. If I had to guess from this I would say that there is something in your httpd.conf (that Apache::test is pulling the config from) that is screwing up the tests. Can you send me your t/httpd.conf? (privately, no need to send it to the list). Regards Michael -- Hal 9000 - "Put down those Windows disks Dave Dave? DAVE!!"
Installing Apache::AuthCookie
Hi, I'm running into a problem during the make test while installing the current version of Apache::AuthCookie. I'm not sure where to go. I looked at tests 10 and 15: Test 10 is supposed to fail: and it did Test 15 is supposed to be FORBIDDEN Should I go ahead and do "make install"? Jay I installed apache, mod_ssl... via apt-get install Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6g mod_perl/1.26 conf meir:/usr/local/cpan/build/Apache-AuthCookie-3.04# make test TEST_VERBOSE=1 t/httpd -f `pwd`/t/httpd.conf PERL_DL_NONLAZY=1 PORT=8228 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/per /5.6.1 -I/usr/share/perl/5.6.1 -e 'use Test::Harness qw(&runtests $verbose); $v rbose=1; runtests @ARGV;' t/*.t t/real1..17 ok 1 ok 2 ok 3 ok 4 code: 302 ok 5 ok 6 ok 7 ok 8 ok 9 code: 401 not ok 10 Result: Connection: close Date: Tue, 10 Jun 2003 19:16:26 GMT Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6g mod_ erl/1.26 Content-Type: text/html; charset=iso-8859-1 Client-Date: Tue, 10 Jun 2003 19:16:26 GMT Client-Peer: 127.0.0.1:8228 Client-Response-Num: 1 Client-Transfer-Encoding: chunked Client-Warning: Missing Authenticate header Title: 401 Authorization Required X-Pad: avoid browser bug Expected: Location: /docs/protected/get_me.html Set-Cookie: Sample::AuthCookieHandler_WhatEver=programmer:Heroo; path=/ Code: 302 ok 11 ok 12 ok 13 Location: /docs/authany/get_me.html Set-Cookie: Sample::AuthCookieHandler_WhatEver=some-user:mypassword; path=/ Code: 302 ok 14 code: 200 not ok 15 Result: Connection: close Date: Tue, 10 Jun 2003 19:16:26 GMT Accept-Ranges: bytes ETag: "1a4039-a8-3ce29115" Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6g mod_ erl/1.26 Content-Length: 168 Content-Type: text/html Last-Modified: Wed, 15 May 2002 16:47:17 GMT Client-Date: Tue, 10 Jun 2003 19:16:26 GMT Client-Peer: 127.0.0.1:8228 Client-Response-Num: 1 Title: Congratulations Expected: ok 16 ok 17 FAILED tests 10, 15 Failed 2/17 tests, 88.24% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/real.t 172 11.76% 10 15 Failed 1/1 test scripts, 0.00% okay. 2/17 subtests failed, 88.24% okay. make: *** [run_tests] Error 11
RE: Apache::AuthCookie and what's required
Now THAT makes perfect sense to me! However that's not what you'll find here: http://www.perldoc.com/cpan/Apache/AuthCookie.html This will step through the require directives you've given for protected documents and make sure the user passes muster. The require valid-user and require user joey-jojo directives are handled for you. You can implement custom directives, such as require species hamster, by defining a method called hamster() in your subclass, which will then be called. The method will be called as $r->hamster($r, $args), where $args is everything on your require line after the word hamster. The method should return OK on success and FORBIDDEN on failure. Here you'll say that it'll call the method hamster! What do you think of that ? Typo ? > it's the other way round: > > if you say in httpd.conf > require species hamster > > Apache::AuthCookie will call > species() in your subclass and passing "haster" in $args > > >From perldoc Apache::AuthCookie: > > o authorize() > This will step through the "require" directives you've > given for protected documents and make sure the user > passes muster. The "require valid-user" and "require > user joey-jojo" directives are handled for you. You > can implement custom directives, such as "require > species hamster", by defining a method called > "species()" in your subclass, which will then be > called. The method will be called as "$r->species($r, > $args)", where "$args" is everything on your "require" > line after the word "hamster". The method > should return OK on success and FORBIDDEN on failure. > > -- > #!/usr/bin/perl http://domm.zsi.at > for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/} >
Re: Apache::AuthCookie and what's required
Hi! On Tue, Jan 07, 2003 at 11:20:25AM +0100, [EMAIL PROTECTED] wrote: > From perldoc Apache::AuthCookie: > > o authorize() > This will step through the "require" directives you've > given for protected documents and make sure the user > passes muster. The "require valid-user" and "require > user joey-jojo" directives are handled for you. You > can implement custom directives, such as "require > species hamster", by defining a method called > "species()" in your subclass, which will then be > called. The method will be called as "$r->species($r, > $args)", where "$args" is everything on your "require" > line after the word "hamster". The method > should return OK on success and FORBIDDEN on failure. After reading this again, I wonder if there is an error in the doc. Shouldn't this $args)", where "$args" is everything on your "require" line after the word "hamster". The method ^ be $args)", where "$args" is everything on your "require" line after the word "species". The method ^ ? -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: Apache::AuthCookie and what's required
Hi! On Tue, Jan 07, 2003 at 09:30:32AM -, Gareth Kirwan wrote: > Hence I'm thinking that I'll need something using the model of require > species hamster ( from Apache::AuthCookie documentation ) > However I can't find out the significance of the word species ... > > hamster is the subroutine in the subclass that will be called and sent $r > and $args, but where does the notion of species come from ? it's the other way round: if you say in httpd.conf require species hamster Apache::AuthCookie will call species() in your subclass and passing "haster" in $args >From perldoc Apache::AuthCookie: o authorize() This will step through the "require" directives you've given for protected documents and make sure the user passes muster. The "require valid-user" and "require user joey-jojo" directives are handled for you. You can implement custom directives, such as "require species hamster", by defining a method called "species()" in your subclass, which will then be called. The method will be called as "$r->species($r, $args)", where "$args" is everything on your "require" line after the word "hamster". The method should return OK on success and FORBIDDEN on failure. -- #!/usr/bin/perl http://domm.zsi.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Apache::AuthCookie and what's required
Title: Gareth Stationery Morning all, Diving straight in... This is my first time using Apache::AuthCookie for Authorization and Authentication ... but when I've been pencilling my plan out I'm already afraid I might need to go a different route - so I thought I'd post here and see what kind of response I got. My problem is that I can't find enough documentation on how to use the further require statements. The user's group is defined in a database, and so is the access level of the page requested. Hence I'm thinking that I'll need something using the model of require species hamster ( from Apache::AuthCookie documentation ) However I can't find out the significance of the word species ... hamster is the subroutine in the subclass that will be called and sent $r and $args, but where does the notion of species come from ? Hope this question is too bad :D Cheers Gareth KirwanProgramming & Development,Thermeon Europe Ltd,[EMAIL PROTECTED] Tel: +44 (0) 1293 864 303Thermeon Europe e-Card: gbjk
Re: Apache::AuthCookie in mod_perl 1.99_5
Any comments? AuthCookie has not yet been ported to mod_perl 2.0. Mike
Apache::AuthCookie in mod_perl 1.99_5
I recently started testing experimental mod_perl 2.0, and almost immediately run into following problem: Apache::AuthCookie (3.04) wants to set auth_type of connection/request/whatever, but there no longer exists any method in Apache::blahblah that allows me to set the auth_type/auth_name of request/connection. There's still corresponding method to _GET_ the auth_type/auth_name, but it doesn't allow setting them any more. I haven't looked the module thoroughly so I haven't figured yet, whether this is needed or not. Any comments?
Apache::AuthCookie causing "Use of uninitialized value." in errorlog...
Hi All, I have written some code that seems to work fine with no perl warnings in the error log... and i was using it quite successfully using Apache::AuthCookie under mod_perl. However, when i put this in my apache configuration file: PerlFixupHandler Apache::AuthCookie->recognize_user I start getting the following warning message in my apache error log file: Use of uninitialized value. The software is still working fine, but its just annoying to see this warning message appear in the file. Has anyone else had this issue? I modified my copy of Apache/AuthCookie.pm to ensure that its recognize_user had no chance of having uninitialized vars, but i still got the message...!!! simran.
Apache::AuthCookie weirdness
I'm experiencing a really strange problem with Apache::AuthCookie and Internet Explorer. Every now and then when I try and access a protected URL, I never see the login page. If I close the window, and open a new one, it works just fine. This is the case even if there are other windows open. In otherwords, I don't have to close all the IE windows to get in. I do not know if this same error occurs with Mozilla. If I inspect the logs, I see this: (with Apache::AuthCookie debugging turned on): (Application Server Error Log) [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ (Application Server Access Log) 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.0" 403 1542 The browser and the server are locked in this conversation where the browser continually requests the protected URI. If I look in the access logs, I see this: (Front-end light Proxy Logs) xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /styles.css HTTP/1.1" 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.1" 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /styles.css HTTP/1.1" 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.1" 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /styles.css HTTP/1.1" 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.1" 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /styles.css HTTP/1.1" 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.1" 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /styles.css HTTP/1.1" 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.1" 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /styles.css HTTP/1.1" 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] "GET /rc/ HTTP/1.1" 200 1542 Any ideas what's going on? It almost seems like AuthCookie is getting confused and not redirecting the user to the correct URL - instead of the login page, it get's redirected back to the initial url, which is protected, and thus starts the entire cycle over again. Proxy: Apache/1.3.23 (Unix) mod_gzip/1.3.19.1a mod_ssl/2.8.7 OpenSSL/0.9.6c App: Apache/1.3.23 (Unix) mod_perl/1.26 Perl: 5.6.1 Apache::AuthCookie: 3.02 -klm.
[ANNOUNCE] Apache-AuthCookie 3.02
The uploaded file Apache-AuthCookie-3.02.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.02.tar.gz size: 29015 bytes md5: 107408d13a43cfbe2d2eccce40adffbe Changes: --- Version: 3.02 - Add support for AuthNameSatisfy directive (can be Any/All, default: Any) - Move cookie path setting into get_cookie_path() so that users can overload this function if they desire (Thanks Raj Chandran) - POST -> GET conversion was broken (r->content called twice). Fixed. Version: 3.01 - adopted support for custom_errors() hook from [EMAIL PROTECTED] - Fixed incorrect documentation in authorize() (thanks to David Young). - login() handler changes: o if "destination" isnt in posted data, set AuthCookieReason to no_cookie and return to login_form (previously just returned SERVER_ERROR). o if authen_cred() returns false, set AuthCookieReason to bad_credentials and return to the login form. o try to handle POST -> GET conversion. - CGI::Util dependency removed (these are internal subroutines for CGI.pm) - ${AuthName}Path will default to "/" if it is not specified (MSIE 6.0 wont set cookies without path) - fix login() handler change so that destination doesnt get lost on subsequent login attempts (thanks Phillip Molter) --- As usual, it may take a few hours for this to propogate to the CPAN mirrors. Regards, Mike
Re: location of LoginScript in Apache::AuthCookie* modules
> "ED" == Eric Doutreleau <[EMAIL PROTECTED]> writes: ED> Right now i would like to make user authenticate throug a SSL ED> page. ED> In order to do that i modify the configuration script to use ED> PerlSetVar WhatEverLoginScript https://corbeau/perl/login.pl Well, in order to be able to get the original location, this has to be done via an internal redirect. When you switch protocols (ie, from http to https) you cannot do internal redirect. But really, your login page doesn't need to be ssl secured as there is no information in it. What you want is the target of the from in that page to be aimed at an SSL URL. That's the transaction you want secured, since that's where the id/password are sent. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
location of LoginScript in Apache::AuthCookie* modules
Hi I 'm trying to use the Apache::AuthCoookieLDAP module to authenticate my web users using my ldap server. With the defaut configuration it works quite well. Right now i would like to make user authenticate throug a SSL page. In order to do that i modify the configuration script to use PerlSetVar WhatEverLoginScript https://corbeau/perl/login.pl it work almost ok ( the cookie is set ) but in the login.pl script i didn't get where i caome from. Therefore i can't set the destination parameter. has someone already done what i try to do before i m trying to reinvent the wheel? Thanks in advance for any help -- Eric Doutreleau I.N.T | Tel : +33 (0) 160764687 9 rue Charles Fourier | Fax : +33 (0) 160764321 91011 Evry France | email : [EMAIL PROTECTED]
Re: Problems with Apache-AuthCookie mod_perl 1.99
Michael, I've got most of the changes done. No major changes were required but I'm still stuck on mod_perl 2's new method handlers. To get past this hurdle I've moved away from method handlers and put everything into a single package. As soon as somebody gives me a hand with method handlers ala 2.0 I'll forward the code to you. -pete Michael J Schout wrote: > On Thu, 2 May 2002, Per Einar Ellefsen wrote: > > > At 21:25 02.05.2002, Peter Rothermel wrote: > > >greetings, > > > > > >Has anybody had any luck getting Apache-AuthCookie going > > >on an Apache 2.0 / mod_perl 1.99 setup? The first thing that > > >I hit was $r->connection->user is deprecated. I've changed these > > >to $r->user. The next hurdle is that the status code REDIRECT > > >does not seen to be Apache::Constants. > > > > mod_perl 2 doesn't have Apache::Constants. You should use: > > > > use Apache::Const -compile => qw(... REDIRECT ..); > > > > Good luck on porting it to mod_perl 2! once you get it to work, it would be > > great if you could contribute it to the community! > > If you do get it working, feel free to forward patches to me as I am the > AuthCookie maintainer. > > An apache 2.0 port is on my TODO list. > > Mike
Re: Problems with Apache-AuthCookie mod_perl 1.99
On Thu, 2 May 2002, Per Einar Ellefsen wrote: > At 21:25 02.05.2002, Peter Rothermel wrote: > >greetings, > > > >Has anybody had any luck getting Apache-AuthCookie going > >on an Apache 2.0 / mod_perl 1.99 setup? The first thing that > >I hit was $r->connection->user is deprecated. I've changed these > >to $r->user. The next hurdle is that the status code REDIRECT > >does not seen to be Apache::Constants. > > mod_perl 2 doesn't have Apache::Constants. You should use: > > use Apache::Const -compile => qw(... REDIRECT ..); > > Good luck on porting it to mod_perl 2! once you get it to work, it would be > great if you could contribute it to the community! If you do get it working, feel free to forward patches to me as I am the AuthCookie maintainer. An apache 2.0 port is on my TODO list. Mike
Re: Problems with Apache-AuthCookie mod_perl 1.99
At 21:25 02.05.2002, Peter Rothermel wrote: >greetings, > >Has anybody had any luck getting Apache-AuthCookie going >on an Apache 2.0 / mod_perl 1.99 setup? The first thing that >I hit was $r->connection->user is deprecated. I've changed these >to $r->user. The next hurdle is that the status code REDIRECT >does not seen to be Apache::Constants. mod_perl 2 doesn't have Apache::Constants. You should use: use Apache::Const -compile => qw(... REDIRECT ..); Good luck on porting it to mod_perl 2! once you get it to work, it would be great if you could contribute it to the community! -- Per Einar Ellefsen [EMAIL PROTECTED]
Problems with Apache-AuthCookie mod_perl 1.99
greetings, Has anybody had any luck getting Apache-AuthCookie going on an Apache 2.0 / mod_perl 1.99 setup? The first thing that I hit was $r->connection->user is deprecated. I've changed these to $r->user. The next hurdle is that the status code REDIRECT does not seen to be Apache::Constants. -pete
Re: different type of login with Apache::AuthCookie?
Have that proactive signin area forward to a page behind Apache::AuthCookie protection and then have that page forward them right back to where they were? If you don't have frames that would be pretty easy. -Fran Ken Miller wrote: > We currently use Apache::AuthCookie for authentication/authorization, and it > works great. However, we want to make a change to how the login works. > > In addition to having Apache::AuthCookie intercept requests for URL's that > require auth/authz, we would like to provide a signon area on the main page > where the user can proactively sign in. > > Would this be as simple as setting the same cookie (using the same format, > obviously) as Apache::Authcookie is looking for when signon occurs on the > front page? Or, better still, is there a way using A:A itself to do this? > > Thanks! > > -klm. >
different type of login with Apache::AuthCookie?
We currently use Apache::AuthCookie for authentication/authorization, and it works great. However, we want to make a change to how the login works. In addition to having Apache::AuthCookie intercept requests for URL's that require auth/authz, we would like to provide a signon area on the main page where the user can proactively sign in. Would this be as simple as setting the same cookie (using the same format, obviously) as Apache::Authcookie is looking for when signon occurs on the front page? Or, better still, is there a way using A:A itself to do this? Thanks! -klm.
Re: Apache::AuthCookie not set cookie really
> variable path=/agenda was omitted. Explorer 6.0 doesn't set cookie > without path attribute. > I think, it's a good idea to make WhatEverPath required option in > config. Hrm. I was not aware of that. Thanks for bringing it to my attention. I have changed AuthCookie in CVS so that Path will be set to "/" unless the path has been configured. This will allow people who have configurations that dont specify the path to still use the new version without updating the config. Feel free to grab the source from CVS and try it out at: http://sourceforge.net/projects/ap-authcookie Mike
Re: Apache::AuthCookie not set cookie really
Skipped > Actually, as my application should be > 1. simple maintained, > 2. maximum count of users - 100 (employees in small software > development company) > 3. simultaneous login - 5-7 maximum > 4. team managers work with money (project budjet, employee's payment > per hour and etc) > 5. good session solutions require database access while all, what I > want to store in sessions, can get from the same database with no > great effort > > I've decided to use simplest authentication module kinda > Apache::DBILogin and if someone need real security - SSL. I meant Apache::AuthDBI of course > > Thank you > > Sergey Polyakov aka "BeerBong" > Chief of WebZavod http://www.webzavod.ru > Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 > mailto:[EMAIL PROTECTED] > > > > >
Re: Apache::AuthCookie not set cookie really
> > > > SetHandler perl-script > > PerlHandler Apache::Agenda > > > > PerlSetVar AgendaPath /agenda > > PerlSetVar AgendaTemplate default.inc > > PerlSetVar AgendaSessionDir /tmp > > PerlSetVar AgendaLoginScript /agenda/login/ > > Are you sure that last line is correct? > > That would send you to /agenda/login when authen_ses_key() fails, but > your config below is for /LOGIN/. > > > > > AuthType Apache::AuthCookieAgenda > > AuthName Agenda > > SetHandler perl-script > > PerlHandler Apache::AuthCookieAgenda->login > > > > This implies to me that you meant to have: > > PerlSetVar AgendaLoginScript /LOGIN/ > > Is this just a typo? > > > 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... > > I dont think they conflict. I've not heard any reports of that anyway. > The cookie names are unique so there should be no problem there. > > > I dont know why cookie is not set. > > I'd suspect something isnt right with your configuration. Have you > tried turning on "warn me before accepting cookies" on your browser? > Sometimes that helps me verify that the cookies are actually making it > to the browser. > > What your trying to do looks to me like exactly the sort of thing > AuthCookie can do. Unless I am misunderstanding your problem I > dont see an AuthCookie limitation here. Please explain in more > detail if I am missing the point and I will see what we can do if > such a limitation does in fact exist :). > > Regards, > Michael Schout (Apache::AuthCookie maintainer) 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 SetHandler perl-script PerlHandler Apache::AuthCookieAgenda->login Problem was here - AgendaPath variable is set in /agenda.* location /LOGIN/ script, which set session key cookie header, doesn't see AgendaPath, therefore Cookie was a Apache::AuthCookieAgenda_Agenda=login:password variable path=/agenda was omitted. Explorer 6.0 doesn't set cookie without path attribute. I think, it's a good idea to make WhatEverPath required option in config. with config PerlSetVar AgendaPath /agenda SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ . AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda->login all works fine. Actually, as my application should be 1. simple maintained, 2. maximum count of users - 100 (employees in small software development company) 3. simultaneous login - 5-7 maximum 4. team managers work with money (project budjet, employee's payment per hour and etc) 5. good session solutions require database access while all, what I want to store in sessions, can get from the same database with no great effort I've decided to use simplest authentication module kinda Apache::DBILogin and if someone need real security - SSL. Thank you Sergey Polyakov aka "BeerBong" Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED]
Re: Apache::AuthCookie not set cookie really
> > SetHandler perl-script > PerlHandler Apache::Agenda > > PerlSetVar AgendaPath /agenda > PerlSetVar AgendaTemplate default.inc > PerlSetVar AgendaSessionDir /tmp > PerlSetVar AgendaLoginScript /agenda/login/ Are you sure that last line is correct? That would send you to /agenda/login when authen_ses_key() fails, but your config below is for /LOGIN/. > > AuthType Apache::AuthCookieAgenda > AuthName Agenda > SetHandler perl-script > PerlHandler Apache::AuthCookieAgenda->login > This implies to me that you meant to have: PerlSetVar AgendaLoginScript /LOGIN/ Is this just a typo? > 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... I dont think they conflict. I've not heard any reports of that anyway. The cookie names are unique so there should be no problem there. > I dont know why cookie is not set. I'd suspect something isnt right with your configuration. Have you tried turning on "warn me before accepting cookies" on your browser? Sometimes that helps me verify that the cookies are actually making it to the browser. What your trying to do looks to me like exactly the sort of thing AuthCookie can do. Unless I am misunderstanding your problem I dont see an AuthCookie limitation here. Please explain in more detail if I am missing the point and I will see what we can do if such a limitation does in fact exist :). Regards, Michael Schout (Apache::AuthCookie maintainer)
Re: AuthSession Manager [was] Apache::AuthCookie not set cookie really
> 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
AuthSession Manager [was] Apache::AuthCookie not set cookie really
> 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 > > > > use lib qw(/usr/web/inc /usr/web/dev.webzavod.ru/modules); > use Apache::Agenda; > use Apache::AuthCookieAgenda; > > PerlInitHandler Apache::Reload > PerlSetVar AuthCookieDebug 10 > > > 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 > > > > AuthType Apache::AuthCookieAgenda > AuthName Agenda > SetHandler perl-script > PerlHandler Apache::AuthCookieAgenda->login > > > > > 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::
Apache::AuthCookie not set cookie really
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 use lib qw(/usr/web/inc /usr/web/dev.webzavod.ru/modules); use Apache::Agenda; use Apache::AuthCookieAgenda; PerlInitHandler Apache::Reload PerlSetVar AuthCookieDebug 10 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 AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda->login 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... Sergey Polyakov aka "BeerBong" Chief of WebZavod http://www.webzavod.ru Tel. +7 (8462) 43-93-85 | +7 (8462) 43-93-86 mailto:[EMAIL PROTECTED]
Re: Problems with cookies in Apache::AuthCookie
Charles Day wrote: > key line must come first. I used Portal instead of your PrisInformasjon, > but you get the idea. I tried that, but it made no difference. I must be doing something wrong. I have now tried with a very similar setup on my linux box with apache 1.3.22, mod_perl 1.26 and all other modules fully up to date. No success. I rewrote my login-script to use plain perl instead of embperl. No success. Any other ideas? What should I get with lwp-request? I currently get this: An Error Occurred An Error Occurred 403 Forbidden I thought I should get the login-script output here? In a browser this seemmingly works. How can I test the redirect/cookie stuff? > > # key line must come first > PerlSetVar PortalDBI_SecretKeyFile /somewhere/secured.key > > PerlModule Apache::AuthCookieDBI > PerlSetVar PortalPath / > PerlSetVar PortalLoginScript /login.pl > PerlSetVar AuthCookieDebug 1 > PerlSetVar PortalDomain .mydomain.com > PerlSetVar PortalDBI_DSN 'dbi:Pg:host=someserver port=5432 dbname=somedb' > PerlSetVar PortalDBI_User "username" > PerlSetVar PortalDBI_Password "**" > PerlSetVar PortalDBI_UsersTable "table" > PerlSetVar PortalDBI_UserField "userid" > PerlSetVar PortalDBI_PasswordField "passwd" > PerlSetVar PortalDBI_SessionLifeTime 00-12-00-00 > > FilesMatch "\.pl"> > AuthType Apache::AuthCookieDBI > AuthName Portal > SetHandler perl-script > PerlHandler Apache::Registry > Options +ExecCGI > PerlSendHeader On > > > # login.pl > > AuthType Apache::AuthCookieDBI > AuthName Portal > SetHandler perl-script > PerlHandler Apache::AuthCookieDBI->login > > > # website. > > PerlSetVar PortalDomain .mydomain.com > PerlSetVar PortalLoginScript /login.pl > AuthType Apache::AuthCookieDBI > AuthName Portal > PerlAuthenHandler Apache::AuthCookieDBI->authenticate > PerlAuthzHandler Apache::AuthCookieDBI->authorize > require valid-user > > >>Here are the relevant parts (I think) from httpd.conf: >> >>PerlSetVar PrisInformasjonPath / >>PerlSetVar PrisInformasjonLoginScript /wwwappl/login.epl >>PerlSetVar PrisInformasjonDomain .tollpost.no >>PerlSetVar PrisInformasjonDBI_DSN "DBI:Informix:testogj1" >>PerlSetVar PrisInformasjonDBI_SecretKeyFile /etc/opt/apache/secret.key >>PerlSetVar PrisInformasjonDBI_UserField "username" >>PerlSetVar AuthCookieDebug 3 >> >>PerlModule Apache::AuthCookieDBI >> >> >> AuthType Apache::AuthCookieDBI >> AuthName PrisInformasjon >> PerlAuthenHandler Apache::AuthCookieDBI->authenticate >> PerlAuthzHandler Apache::AuthCookieDBI->authorize >> require valid-user >> >> >> >> AuthType Apache::AuthCookieDBI >> AuthName PrisInformasjon >> SetHandler perl-script >> PerlHandler Apache::AuthCookieDBI->login >> >> -- Øyvind ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. (mailto:[EMAIL PROTECTED]) This footnote also confirms that this email message has been swept by viruscheckers for the presence of computer viruses. **
Re: Problems with cookies in Apache::AuthCookie
Øyvind Gjerstad wrote: > > Geoffrey Young wrote: > > >>[Fri Jan 4 14:23:46 2002] [error] credential_0 ogj > >>[Fri Jan 4 14:23:46 2002] [error] credential_1 xxx > >>[Fri Jan 4 14:23:46 2002] [error] ses_key > >>ogj:2002-01-04-14-23-46:2002-01-05-14 > >>-23-46:54f7553ccb96d3af70abe449f053ee3d > >>[Fri Jan 4 14:23:46 2002] [error] auth_type Apache::AuthCookieDBI > >> > > > > the AuthType setting should be the name of the class that inherits > > from Apache::AuthCookie (or Apache::AuthCookieDBI I suppose, I've > > never used it) > > > > for instance > > > > PerlSetVar PrisInformasjonPath / > > PerlSetVar PrisInformasjonLoginScript /login.html > > PerlSetVar AuthCookieDebug 3 > > > > > > AuthType PrisInformasjon::Authenticate > > AuthName PrisInformasjon > > PerlAuthenHandler PrisInformasjon::Authenticate->authenticate > > Require vaild-user > > Hmm. I thought I didn't need to subclass AuthCookieDBI. I thought that I > should be able to just configure that to authenticate to a database > (that part works, as far as I can tell), and write a login-script (which > I have done). ah, you are right. I don't use Apache::AuthCookieDBI, and apparently it works slightly differently from Apache::AuthCookie. anyway, CC'd to the list so perhaps someone more familiar can see your httpd.conf --Geoff > > Here are the relevant parts (I think) from httpd.conf: > > PerlSetVar PrisInformasjonPath / > PerlSetVar PrisInformasjonLoginScript /wwwappl/login.epl > PerlSetVar PrisInformasjonDomain .tollpost.no > PerlSetVar PrisInformasjonDBI_DSN "DBI:Informix:testogj1" > PerlSetVar PrisInformasjonDBI_SecretKeyFile /etc/opt/apache/secret.key > PerlSetVar PrisInformasjonDBI_UserField "username" > PerlSetVar AuthCookieDebug 3 > > PerlModule Apache::AuthCookieDBI > > > AuthType Apache::AuthCookieDBI > AuthName PrisInformasjon > PerlAuthenHandler Apache::AuthCookieDBI->authenticate > PerlAuthzHandler Apache::AuthCookieDBI->authorize > require valid-user > > > > AuthType Apache::AuthCookieDBI > AuthName PrisInformasjon > SetHandler perl-script > PerlHandler Apache::AuthCookieDBI->login > > > >>[Fri Jan 4 14:23:46 2002] [error] auth_name PrisInformasjon > >>[Fri Jan 4 14:23:46 2002] [error] ses_key_cookie > >>[Fri Jan 4 14:23:46 2002] [error] uri /tgweb/protected/index.html > > -- > Øyvind > > ** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. (mailto:[EMAIL PROTECTED]) > > This footnote also confirms that this email message has been swept by > viruscheckers for the presence of computer viruses. > **
Problems with cookies in Apache::AuthCookie
I'm trying to get Apache::AuthCookie and Apache::AuthCookieDBI to work. However it seems like I can't set any cookies. I have cookies enabled in my browser (with warnings), but I can't read the cookie after the redirect from the login-script. I'm pretty sure the cookie is never sent to the browser. How can I check if the redirect is happening? Here is the log with AuthCookieDebug set to 3: [Fri Jan 4 14:23:46 2002] [error] credential_0 ogj [Fri Jan 4 14:23:46 2002] [error] credential_1 xxx [Fri Jan 4 14:23:46 2002] [error] ses_key ogj:2002-01-04-14-23-46:2002-01-05-14 -23-46:54f7553ccb96d3af70abe449f053ee3d [Fri Jan 4 14:23:46 2002] [error] auth_type Apache::AuthCookieDBI [Fri Jan 4 14:23:46 2002] [error] auth_name PrisInformasjon [Fri Jan 4 14:23:46 2002] [error] ses_key_cookie [Fri Jan 4 14:23:46 2002] [error] uri /tgweb/protected/index.html I get a ses_key, but no value in ses_key_cookie. I tried to dump all headers to the log, but there were no signs of any cookie-related things. I must admit that I don't quite understand how the setting of WhatEverPath (in my case "PrisInformasjonPath") relates to the rest of my configuration. Btw: is setting a cookie and then doing a redirect safe with all browsers (at least those with cookies turned on)? Using AuthCookie 3.00 and AuthCookieDBI 1.18, mod_perl 1.25, perl 5.005_03 under Apache 1.3.19, HP-UX 10.20. Currently testing with Mozilla 1.9.6, Linux. Thanks, -- Øyvind ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. (mailto:[EMAIL PROTECTED]) This footnote also confirms that this email message has been swept by viruscheckers for the presence of computer viruses. **
Problem with Apache::AuthCookie
Getting multiple header entries from AuthCookie returned to the client. This happens even if I stub out the authen_cred and authen_ses_key to return "foo". Other thing I notice after adding logging to the authentication and authorization sub's is that the $r->connection->user set by authentication isn't available in $r->connection->user in authorization. As a result of the undef $r->connection->user in authorization it's sending back a FORBIDDEN which [I think?] causes the problems. The examples I've seen of login_form code use a simple print to get things on the screen (e.g., Apache::AuthTicket). I've tried this and various combinations of sending the headers and form with no luck. Ideally Apache::AuthCookie should only require the login_form, authen_cred and authen_ses_key sub's to function with the addition of login_screen to use a location rather rather than #!-ed code for the login form. Does anyone know of a simple, working example of deriving a class from Apache::AuthTicket or some specific documentation for a complete class? The code that comes with it is only useful for testing Below are the relavant error_log items (showing the user available in authenticate and undef in authorize). thanx. sl # Authorization cookie handler. PerlModule Cdr::AuthCookie; PerlSetVar CDRPath /foo PerlSetVar CDRLoginScript /cdrloginform PerlSetVar CDRLoginHandler /cdrlogin #PerlSetVar CDRExpires +8h PerlSetVar AuthCookieDebug 9 # this shows the login form. SetHandler perl-script PerlHandler Cdr::AuthCookie->login_form # handle posted data from the login form. SetHandler perl-script AuthTypeCdr::AuthCookie AuthNameCDR PerlHandler Cdr::AuthCookie->login SetHandler perl-script AuthTypeCdr::AuthCookie AuthNameCDR PerlAuthenHandler Cdr::AuthCookie->authenticate PerlAuthzHandlerCdr::AuthCookie->authorize PerlHandler Cdr::Hello require valid-user SetHandler perl-script AuthTypeCdr::AuthCookie AuthNameCDR PerlAuthenHandler Cdr::AuthCookie->authenticate PerlAuthzHandlerCdr::AuthCookie->authorize PerlHandler Cdr::Hello require valid-user ### # Cdr::AuthCookie.pm ####### package Cdr::AuthCookie; use strict; use base qw( Apache::AuthCookie ); local $\ = "\n"; local $, = "\n"; # CPAN modules use Carp; use Apache::Constants qw(:common M_GET M_POST FORBIDDEN REDIRECT); use Apache::Log; use Digest::MD5 qw( &md5_hex ); # used for sharing and generating the shared secret # used in the authrization process. use IPC::SysV; use IPC::Shareable; use Digest::MD5 qw( &md5_hex ); use Data::Dumper; $Data::Dumper::Purity = 1; $Data::Dumper::Terse= 1; $Data::Dumper::Indent = 1; $Data::Dumper::Deepcopy = 0; $Data::Dumper::Quotekeys= 0; # homegrown modules use Cdr::Reportz; use Cdr::Shared qw( &logrequest &sendreply ); # package variables # initialize the untied variable to false, use $key to check the status. our $secret = ''; our $key = ''; # amount of time before a cookie times out. # currently set to 8 hours (28 800 sec). # # 10 sec for testing only, probably useful in production. my $timeout = 30; #28800; # login screen returns this to the caller. my $loginform = <<'END'; Please Enter Your Username and Password to log in:" Username: Password: END # subroutines =head2 sub B Trick here is to hash the information with a secret and then hash the hash with the values. This makes it virtually impossible f
Re: Problem with Apache::AuthCookie-3.00
Well, I didn't see any other replies to this... so I'll comment: I don't get what you are saying here... Could you rephrase it and clarify if you are talking about AuthTicket or AuthCookie? > From: Steven Lembark <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Fri, 07 Dec 2001 01:34:57 -0600 > To: [EMAIL PROTECTED] > Subject: Problem with Apache::AuthCookie-3.00 > > > Getting multiple HTTP replies returned to the client. They > get a form and followig it an 'access denied' message from > Apache. > > The examples I've seen of login_form code use a simple print to > get things on the screen (e.g., Apache::AuthTicket). > I've tried this and various combinations of sending the headers > and form with no luck. > > Ideally Apache::AuthCookie should only require the login_form, > authen_cred and authen_ses_key sub's to function with the > addition of login_screen to use a location rather rather than > #!-ed code for the login form. > > Does anyone know of a simple, working example of deriving a > class from Apache::AuthTicket or some specific documentation > for a complete class? The code that comes with it is only > useful for testing; the other modules include quit a bit of > non-AuthCookie sub's that may have a bearing on how the > form is handled. The login_form is taken from Apache::AuthTicket > (basically just a header and static body). > > My sub-class also overloads authentication to call login_form($r) > rather than without arguments. > > sub authen_cred( $$\@ ) { "foo" } > > sub authen_ses_key( $$$ ) { "foo" } > > sub login_form > { > my( $class, $request ) = @_; > > $request->no_cache( 1 ); > $request->send_http_header( 'text/html' ); > $request->print( $form ); > > OK > } > > > > -- > Steven Lembark 2930 W. Palmer > Workhorse Computing Chicago, IL 60647 > +1 800 762 1582 >
Problem with Apache::AuthCookie-3.00
Getting multiple HTTP replies returned to the client. They get a form and followig it an 'access denied' message from Apache. The examples I've seen of login_form code use a simple print to get things on the screen (e.g., Apache::AuthTicket). I've tried this and various combinations of sending the headers and form with no luck. Ideally Apache::AuthCookie should only require the login_form, authen_cred and authen_ses_key sub's to function with the addition of login_screen to use a location rather rather than #!-ed code for the login form. Does anyone know of a simple, working example of deriving a class from Apache::AuthTicket or some specific documentation for a complete class? The code that comes with it is only useful for testing; the other modules include quit a bit of non-AuthCookie sub's that may have a bearing on how the form is handled. The login_form is taken from Apache::AuthTicket (basically just a header and static body). My sub-class also overloads authentication to call login_form($r) rather than without arguments. sub authen_cred( $$\@ ) { "foo" } sub authen_ses_key( $$$ ) { "foo" } sub login_form { my( $class, $request ) = @_; $request->no_cache( 1 ); $request->send_http_header( 'text/html' ); $request->print( $form ); OK } -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Apache::AuthCookie login faliure reason
> "CH" == Carolyn Hicks <[EMAIL PROTECTED]> writes: CH> this to something like 'InvalidLogin' in authen_cred, you can then check CH> for this and set the reason via $r->subprocess_env in AuthCookieHandler-> authen_ses_key, before AuthCookie->authenticate wipes CH> the cookie out. Not extensively tested, but seems to work so far :) This is what I do. Unfortunately the diagram in AuthCookie man page is incorrect in that returning undef from authen_cred sends you back to the login screen (last I checked), so one must pull these tricks. my %errors = ( 'badpass' => 'Sorry, your login information is incorrect. Please try again.', 'suspended' => 'Sorry, your account is supended. Please contact us for assistance.', 'sessfail' => 'Sorry, there was a problem establishing your session. Please try again.', 'terminated' => 'Sorry, this account has been cancelled. Please create a new one.', ); # Check credentials in database. If failure, return 'ERROR:code' # where code is from %errors hash. On success, return the cookie sub authen_cred ($$\@) { my $self = shift; my $r = shift; my ($acct,$password,$isAdmin) = @_; Apache->request($r); # need to set for openDB(). my $dbh = openDB() or return 'ERROR:sessfail'; # first, check id/password from database my $orec = new orec() or return 'ERROR:sessfail'; my $oid = $orec->acct_to_id($acct) or return 'ERROR:badpass'; eval { $orec->populate_id($oid); }; return 'ERROR:badpass' if ($@ and $@ =~ m/^notfound/); return 'ERROR:terminated' if $orec->owner_status() eq 'terminated'; $orec->verify_password($password) or return 'ERROR:badpass'; # ok, so now create a session for them and use that session ID # as their cookie value my %session; eval { tie %session, 'Apache::Session::Postgres', undef, { Handle => $dbh, Commit => 0, }; }; if ($@) { warn "authen_cred got $@ creating new session"; return 'ERROR:sessfail'; } else { $session{user} = $orec->owner_email(); $session{owner_id} = $orec->owner_id(); if ($isAdmin) { # instantiate the admin record in this session and log that # this admin is impersonating this user. my $arec = arec->new($orec->{_CONTEXT}); $arec->populate_id($arec->decode($isAdmin)); $session{arec} = $arec; $arec->log_action('Logged in as account owner.',$orec); } return $session{_session_id}; } } # upon failure to authenticate the session, set MLMAuthReason environment and # return undef. sub authen_ses_key ($$$) { my $self = shift; my $r = shift; my $key = shift; Apache->request($r); # need to set for openDB(). if ($key =~ m/^ERROR:(\w+)(-\d+)?$/) { # set $r->subprocess_env('MLMAuthReason') to failure reason $r->subprocess_env('MLMAuthReason' => $errors{$1}); return undef; } # Check if key is in database. my %session; eval { my $dbh = openDB(); tie %session, 'Apache::Session::Postgres', $key, { Handle => $dbh, Commit => 0, }; }; if ($@) { warn "authen_ses_key got $@ retrieving session `$key'"; $r->subprocess_env('MLMAuthReason' => 'Unable to retrieve session. Possibly expired. Please login again.'); return undef; } else { # got the session... now stash it away for later use $r->pnotes('sessionkey',$key); $r->pnotes('sessionhashref',\%session); $r->pnotes('owner_id',scalar($session{owner_id})); return $session{user}; } } -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Apache::AuthCookie login faliure reason
Bill Moseley wrote: > > At 04:09 PM 11/23/2001 +1100, simran wrote: > >>>> > Hi All, > > I am having some trouble getting Apache::AuthCookie (version 3 which i > believe is the latest version) to do what want: > > What i want is: > > * To be able to give the user a reson if login fails > - eg reason: * "No such username" > * "Your password was incorrect" > > Has anyone else come across the same requirement/issue, and how have you > solved it? > > <<<< > Apache::AuthCookieURL does that. IIRC, it sets a cookie with the failure > reason that's returned from authen_cred call. > > >>>> > in the code line 154 is this: $r->subprocess_env('AuthCookieReason', 'bad_cookie'); and on 157 this: $r->subprocess_env('AuthCookieReason', 'no_cookie'); im not sure why your having problems on setting this the examples in the cpan tarball on the login.pl page are like this #!/usr/bin/perl use strict; my $r = Apache->request; $r->status(200); my $uri = $r->prev->uri; my $reason = $r->prev->subprocess_env("AuthCookieReason"); then in his html code it says: Failure reason: '$reason'. Please enter your login and password to authenticate. which shows up if its a 'bad cookie' or 'no cookie' basically the authentication failed one thing to mention in the prev not prev subprocess is that you set it as subprocess_env and then call it with prev later
Re: Apache::AuthCookie login faliure reason
At 04:09 PM 11/23/2001 +1100, simran wrote: >>>> Hi All, I am having some trouble getting Apache::AuthCookie (version 3 which i believe is the latest version) to do what want: What i want is: * To be able to give the user a reson if login fails - eg reason: * "No such username" * "Your password was incorrect" Has anyone else come across the same requirement/issue, and how have you solved it? <<<< Apache::AuthCookieURL does that. IIRC, it sets a cookie with the failure reason that's returned from authen_cred call. >>>> <<<< >>>> Bill Moseley mailto:[EMAIL PROTECTED]
Re: Apache::AuthCookie login faliure reason
>I am having some trouble getting Apache::AuthCookie (version 3 which i >believe is the latest version) to do what want: >What i want is: >* To be able to give the user a reson if login fails > - eg reason: * "No such username" >* "Your password was incorrect" >Has anyone else come across the same requirement/issue, and how have you >solved it? I banged my head up against this same wall for awhile until, by reading AuthCookie's source, I was able to figure out the key to making it all work. In authen_cred (stripped-down example below), you need to set a cookie with a value that your ticket-checking code will know is invalid when you are given invalid credentials. But, in the interest of security, you don't want to say things like "no such username" and "incorrect password" - that just gives extra information to someone trying to hack their way in. sub authen_cred ($$\@) { my $self = shift; my $r = shift; my ($user,$pass) = @_; if ( check_creds($user,$pass) ) { # user's credentials are good, so generate ticket, log session, etc return "$user:$ticket"; } else { # Modify this (and the code above) if you want more shades of # meaning here. return "oops"; } } Then, in authen_ses_key: sub authen_ses_key ($$$) { my $self = shift; my $r = shift; my($user,$ticket) = split(/:/,shift,2); my $retval; return undef unless $user && $ticket; if ( # ticket is good... $retval = # something indicating ticket is good... } else { # ticket is bad, so tell the login program/form about it... $r->subprocess_env('LocalAuthFailure','mumble') if ...; } # I also detect an expired session and indicate it like this: $r->subprocess_env('LocalAuthFailure','expired') unless $retval; if ( $retval ) { my $auth_name = $r->auth_name; # etc... } } After all that, your login program/form just reads "LocalAuthFailure" and acts appropriately: my ($reason,$detail); if ( $r->prev ) { $reason = $r->prev->subprocess_env("AuthCookieReason"); $detail = $r->prev->subprocess_env("LocalAuthFailure"); } #... # Possibly set an error string: my $error; $error = "Authentication error. Please try again." if $reason =~ /bad/; $error = "Your session has expired. Please reauthenticate." if $reason =~ /bad/ && $detail =~ /expire/; # Now interpolate $error into the HTML we send to the browser my $form = < ... $error ... I hope that these code snippets are enough to get you started. ...Steve -- Steve van der Burg Information Services London Health Sciences Centre (519) 685-8300 ext 35559 [EMAIL PROTECTED]
Re: Apache::AuthCookie login faliure reason
On Fri, Nov 23, 2001 at 04:09:45PM +1100, simran wrote: > What i want is: > > * To be able to give the user a reson if login fails > - eg reason: * "No such username" > * "Your password was incorrect" On Thu, Nov 22, 2001 at 09:26:17PM -0800, clayton wrote: > here is the meat of the matter > send something like this to the $r->subprocess_env > $r->subprocess_env('AuthCookieReason2', 'username invalid!'); yeah, but it depends when and where you do that. I found that if I set subprocess_env in the AuthCookieHandler->authen_cred method, which is where the login credentials get checked, it wasn't visible to the login script - this is because a redirect takes place in between, so a whole new request is started. So I had actually been doing something really dodgy to catch invalid logins, but your mention of setting another cookie gave me the idea of using the session key of the authcookie itself. If you set this to something like 'InvalidLogin' in authen_cred, you can then check for this and set the reason via $r->subprocess_env in AuthCookieHandler->authen_ses_key, before AuthCookie->authenticate wipes the cookie out. Not extensively tested, but seems to work so far :) -carolyn
RE: Apache::AuthCookie login faliure reason
Thanks for your response Clayton. Although unfortunately its not working for me as from what i understand: * When a person has to login (asusming they have no cookie set yet), if they enter the wrong credentials "authen_cred" does a _external redirect_ (aka redirects the browser to go to that url again) - hence subprocess_env is not available from a previous request. If the problem was an incorrect cookie however, the subprocess_env would indeed by handy, as authen_ses_key does an internal redirect, hence you can get the "previous requests" subprocess env... simran. -Original Message- From: clayton [mailto:[EMAIL PROTECTED]] Sent: Friday, 23 November 2001 4:26 PM To: simran Cc: [EMAIL PROTECTED] Subject: Re: Apache::AuthCookie login faliure reason yes its pretty easy one to do, btw: i first found out how by investigating the Apache::AuthCookie code here is the meat of the matter send something like this to the $r->subprocess_env {the name im using is the same as authcookie's with the 2 added} $r->subprocess_env('AuthCookieReason2', 'username invalid!'); then in your login.cgi {or handler or w.h.y.} you can do this: my $error=$r->prev->subprocess_env('AuthCookieReason2') ||$r->prev->subprocess_env('AuthCookieReason') ; or use 'defined' or w.h.y. then you can place $error wherever you please hope that helps simran wrote: > Hi All, > > > > I am having some trouble getting Apache::AuthCookie (version 3 which i > believe is the latest version) to do what want: > > > > What i want is: > > > > * To be able to give the user a reson if login fails > > - eg reason: * "No such username" > > * "Your password was incorrect" > > > > Has anyone else come across the same requirement/issue, and how have > you solved it? > > > > It seems like a difficult one to solve (in a clean way) as the only > way i can think of doing it is either setting > > another cookie (with the auth failure reason) or adding to the URL > query parameters and then reading them > > when displaying the login page... > > > > simran. >
Re: Apache::AuthCookie login faliure reason
yes its pretty easy one to do, btw: i first found out how by investigating the Apache::AuthCookie code here is the meat of the matter send something like this to the $r->subprocess_env {the name im using is the same as authcookie's with the 2 added} $r->subprocess_env('AuthCookieReason2', 'username invalid!'); then in your login.cgi {or handler or w.h.y.} you can do this: my $error=$r->prev->subprocess_env('AuthCookieReason2') ||$r->prev->subprocess_env('AuthCookieReason') ; or use 'defined' or w.h.y. then you can place $error wherever you please hope that helps simran wrote: > Hi All, > > > > I am having some trouble getting Apache::AuthCookie (version 3 which i > believe is the latest version) to do what want: > > > > What i want is: > > > > * To be able to give the user a reson if login fails > > - eg reason: * "No such username" > > * "Your password was incorrect" > > > > Has anyone else come across the same requirement/issue, and how have > you solved it? > > > > It seems like a difficult one to solve (in a clean way) as the only > way i can think of doing it is either setting > > another cookie (with the auth failure reason) or adding to the URL > query parameters and then reading them > > when displaying the login page... > > > > simran. >
Apache::AuthCookie login faliure reason
Hi All, I am having some trouble getting Apache::AuthCookie (version 3 which i believe is the latest version) to do what want: What i want is: * To be able to give the user a reson if login fails - eg reason: * "No such username" * "Your password was incorrect" Has anyone else come across the same requirement/issue, and how have you solved it? It seems like a difficult one to solve (in a clean way) as the only way i can think of doing it is either setting another cookie (with the auth failure reason) or adding to the URL query parameters and then reading them when displaying the login page... simran.
Re: Apache::AuthCookie
Rob Bloodgood wrote: > > > > Does anyone know where I can find documentation to install > > > and configure > > > Apache::AuthCookie? The docs that come with it are thin and > > > do not provide > > > much information. > > > > you're kidding, right? > > > > [geoff@jib Apache-AuthCookie-2.011]$ perldoc AuthCookie.pm | wc -l > > 462 > > Verbiage and ASCII art do not good documentation make. > > I'm *not* a newbie, but it took me almost a day to install a RUDIMENTARY > AuthCookie setup... because the docs were so thin. And unclear. > > My $.02. > > L8r, > Rob > > #!/usr/bin/perl -w > use Disclaimer qw/:standard/; my $0.02: i thought it was pretty straight forward tip#1: if your looked/used the ./t/ examples/test directory you should have been up and running in a matter of minutes tip#2: perlmonks.org usually has great examples/forums/answers
RE: Apache::AuthCookie
> > Does anyone know where I can find documentation to install > > and configure > > Apache::AuthCookie? The docs that come with it are thin and > > do not provide > > much information. > > you're kidding, right? > > [geoff@jib Apache-AuthCookie-2.011]$ perldoc AuthCookie.pm | wc -l > 462 Verbiage and ASCII art do not good documentation make. I'm *not* a newbie, but it took me almost a day to install a RUDIMENTARY AuthCookie setup... because the docs were so thin. And unclear. My $.02. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
RE: Apache::AuthCookie
> -Original Message- > From: Recendez, Ray [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 28, 2001 1:45 PM > To: '[EMAIL PROTECTED]' > Subject: Apache::AuthCookie > > > Does anyone know where I can find documentation to install > and configure > Apache::AuthCookie? The docs that come with it are thin and > do not provide > much information. you're kidding, right? [geoff@jib Apache-AuthCookie-2.011]$ perldoc AuthCookie.pm | wc -l 462 --Geoff
Apache::AuthCookie
Does anyone know where I can find documentation to install and configure Apache::AuthCookie? The docs that come with it are thin and do not provide much information. Thanks, Ray
RE: Apache::AuthCookie and ServerSide Include not working
Never mind. A few more eyes showed me that my virtual host was not set up right for SSIs -Original Message- From: Chad Phillips [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 12:13 PM To: mod_perl List Subject: Apache::AuthCookie and ServerSide Include not working Hello, I have apache 1.3.19 running on a Mandrake 8.0 box. I am using authcookie for authentication. I can't seem to get any SSIs to run now. I have another plain install of apache on the same box and SSIs work fine. The only difference I have seen between the two installs is AuthCookie. Has anyone else had a problem running SSIs with Authcookie? thanks chad
Apache::AuthCookie and ServerSide Include not working
Hello, I have apache 1.3.19 running on a Mandrake 8.0 box. I am using authcookie for authentication. I can't seem to get any SSIs to run now. I have another plain install of apache on the same box and SSIs work fine. The only difference I have seen between the two installs is AuthCookie. Has anyone else had a problem running SSIs with Authcookie? thanks chad
CPAN Apache-AuthCookie-3.00.tar.gz (fwd)
The uploaded file Apache-AuthCookie-3.00.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.00.tar.gz size: 25399 bytes md5: 5c94e0ced442653f229b39f4f1fcfe8c Changes since v2.011: - New maintiner: Michael Schout <[EMAIL PROTECTED]> - changed to hard coded $VERSION rather than RCS Revision style. - Revamped testing code to use Apache::test (with minor mods). - Added support for ${AuthName}Expires parameter that can be used to make your cookie persistent. - CGI::Util is now used for parsing the "Expires" parameter. If you are missing this package, you probably need to upgrade your CGI.pm package. As usual, please allow time for this to propogate through the CPAN mirrors. Regards, Mike
Re: Apache::AuthCookie- help on "make test"
Time Co-Ordinate Fri, 18 May 2001 03:35:03 -0700, The Organism labeled Will Waggoner said: > Hi Emma, > > I've gotten this error every time I've run the test for this version of > AuthCookie -- but upon installation it works fine. > i can confirm this
Re: Apache::AuthCookie- help on "make test"
Hi Emma, I've gotten this error every time I've run the test for this version of AuthCookie -- but upon installation it works fine. Will - Original Message - From: "Emma Wermström (EMW)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 18, 2001 2:48 AM Subject: Apache::AuthCookie- help on "make test" > hi all! > > My settings: > RedHat Linux7.1 > Apache 1.3.19 > Perl5.005 > mod_perl1.24 > embperl > > > When I do "make test" during Apache::AuthCookie installation phase I get the following messages. I've included all input and output from the "perl Makefile.PL" and "make" commands. > > [root@localhost Apache-AuthCookie-2.011]# perl Makefile.PL > > For testing purposes, please give the full path to an httpd > with mod_perl and at least the following hooks enabled: PERL_AUTHEN, > PERL_AUTHZ, PERL_STACKED_HANDLERS, PERL_METHOD_HANDLERS. > The path defaults to $ENV{APACHE}, if present. > > [/usr/lib/httpd/httpd]: /etc/rc.d/init.d/httpd > User to run tests under [root]: apache > Group to run tests under [apache]: apache > Port to run tests under [8228]: > Writing Makefile for Apache::AuthCookie > > > [root@localhost Apache-AuthCookie-2.011]# make > > Manifying blib/man3/Apache::AuthCookie.3pm > > [root@localhost Apache-AuthCookie-2.011]# make test > > PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.6.0/i386-linux -I/us r/lib/perl5/5.6.0 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t > t/real..ok 1/12Can't start httpd: Illegal seek at real.t line 171, line 4. > t/real..dubious > Test returned status 29 (wstat 7424, 0x1d00) > DIED. FAILED tests 2-12 > Failed 11/12 tests, 8.33% okay > Failed Test Status Wstat Total Fail Failed List of failed > -- - > t/real.t 29 742412 11 91.67% 2-12 > Failed 1/1 test scripts, 0.00% okay. 11/12 subtests failed, 8.33% okay. > make: *** [test_dynamic] Error 2 > > What am I doing wrong? Please help! > > Emma
Apache::AuthCookie- help on "make test"
hi all! My settings: RedHat Linux7.1 Apache 1.3.19 Perl5.005 mod_perl1.24 embperl When I do "make test" during Apache::AuthCookie installation phase I get the following messages. I've included all input and output from the "perl Makefile.PL" and "make" commands. [root@localhost Apache-AuthCookie-2.011]# perl Makefile.PL For testing purposes, please give the full path to an httpd with mod_perl and at least the following hooks enabled: PERL_AUTHEN, PERL_AUTHZ, PERL_STACKED_HANDLERS, PERL_METHOD_HANDLERS. The path defaults to $ENV{APACHE}, if present. [/usr/lib/httpd/httpd]: /etc/rc.d/init.d/httpd User to run tests under [root]: apache Group to run tests under [apache]: apache Port to run tests under [8228]: Writing Makefile for Apache::AuthCookie [root@localhost Apache-AuthCookie-2.011]# make Manifying blib/man3/Apache::AuthCookie.3pm [root@localhost Apache-AuthCookie-2.011]# make test PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.6.0/i386-linux -I/usr/lib/perl5/5.6.0 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/real..ok 1/12Can't start httpd: Illegal seek at real.t line 171, line 4. t/real..dubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 2-12 Failed 11/12 tests, 8.33% okay Failed Test Status Wstat Total Fail Failed List of failed --- t/real.t 29 742412 11 91.67% 2-12 Failed 1/1 test scripts, 0.00% okay. 11/12 subtests failed, 8.33% okay. make: *** [test_dynamic] Error 2 What am I doing wrong? Please help! Emma
Re: using Apache::AuthCookie and Sample::AuthCookieHandler
On Tue, 15 May 2001, Emma Wermström (EMW) wrote: ... > apache::authcookie (latest version) > > I found this great module that allows login and logout from a web site > using cookies. the problem is that I don't know how to use it myself. > Yes, I've read and reread the documentation that comes with installing > the module. > I want to get an authentication/authorization scheme going for my web > page and I thought I'd get started just using the > Sample::AuthCookieHandler package. Unfortunately I can't check the details for you now, but I've done some experimentation with Apache::AuthCookie and came up with my own subclass Apache::AuthCookie::AuthPAM. You can get it from http://www.saunalahti.fi/~juhaml/Apache-AuthCookie-AuthPAM-2.14.tar.gz As the name implies, it uses the PAM (Pluggable Authentication Modules) as the authentication backend. As such, it appears to do the authentication properly, but the temporary session data files will be left behind, so some external cleanup of these files is required. It also includes a small example www directory tree that should help you forward. -- ..Juha
using Apache::AuthCookie and Sample::AuthCookieHandler
hi! RedHat Linux 7.1 apache 1.3.19 perl 5 mod_perl 1.24 embperl (latest version) apache::authcookie (latest version) I found this great module that allows login and logout from a web site using cookies. the problem is that I don't know how to use it myself. Yes, I've read and reread the documentation that comes with installing the module. I want to get an authentication/authorization scheme going for my web page and I thought I'd get started just using the Sample::AuthCookieHandler package. Login.htm is page that displays a form where users can add their credentials. It also includes a hidden field, destination, where the path to the protected page is written, ../CIP/Welcome2.htm At /bla/bla/site/htdocs I have two directories. Intro, which doesn't require authentication/authorization and CIP, which DOES require it. this is how I've configured my httpd.conf file: PerlRequire /usr/src/Apache-AuthCookie-2.011/t/Sample/AuthCookieHandler.pm PerlSetVar /bla/bla/site/htdocs / PerlSetVar perl-script Intro/Login.htm AuthTypeSample::AuthCookieHandler AuthNameDarkness PerlAuthenHandler Sample::AuthCookieHandler->authenticate PerlAuthzHandlerSample::AuthCookieHandler->authorize require valid-user AuthTypeSample::AuthCookieHandler AuthNameDarkness PerlFixupHandlerSample::AuthCookieHandler->recognize_user AuthTypeSample::AuthCookieHandler AuthNameDarkness SetHandler perl-script PerlHandler Sample::AuthCookieHandler->login i don't know how to write the file LOGIN. What does it do? It is also located at /bla/bla/site/htdocs. My server complains that it doesn't have access to it but I've made sure that it is executable for all users. the login.htm page is accessed from the "unprotected" pages in the ../htdocs/Intro directory. I also don't understand how the subroutines are called. If I explicitly want to call login, which parameters do I use? How do I specify package name ($self) and apache request object ($r). I have not altered the subroutines in Apache::AuthCookie and Sample::AuthCookieHandler in any way. I hope there is anyone out there who feels like answering these, probably simple, questions. I've searched the archives already. Thanks for all help! Emma
Apache::AuthCookie transfer of ownership
Hi all, For a long while, it's become clearer and clearer to me that I need to hand off ownership of the Apache::AuthCookie module to someone else. I haven't been able to keep up with the many development requests, even when they've been perfectly reasonable and probably fairly simple to execute. Therefore, I've decided to cede ownership to Michael Schout (the author of Apache::AuthTicket, a subclass of Apache::AuthCookie), who has graciously accepted the offer. He's asked me to provide him an email archive of past feature requests, bug reports, and the like. I'll do that, and if you're still actively hoping to affect some particular change in the module, you might drop him a line directly ([EMAIL PROTECTED]). I'm quite pleased that this neglected module will find a new owner who can take it in new and better directions. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::AuthCookie and SSL
> "JM" == JR Mayberry <[EMAIL PROTECTED]> writes: JM> might wanna modify the source to set the domain to .yourdomain.com, as JM> its probably now being set as secure.yourdomain.com or JM> www.yourdomain.com no need to modify source to do that. AuthCookie has a config option to do it for you.
Re: Apache::AuthCookie and SSL
> "JW" == John Walstra <[EMAIL PROTECTED]> writes: JW> I'm having the problem with being logged out then I switch to a JW> secure document. I have to log back in to get to the page. And JW> when I go from a SSL page to a plain page it logs me out JW> again. Any advise? Figure out how to make your web browser send the cookie to both the SSL and non-SSL versions of your pages. You're not being logged out; the cookie just is not being sent to you. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Apache::AuthCookie and SSL
actually you should be able to do a PerlSetVar to set that as well PetSetVar ApolloDomain .yourdomain.com i think will work John Walstra wrote: > > I'm having the problem with being logged out then I switch to a secure > document. I have to log back in to get to the page. And when I go from a SSL > page to a plain page it logs me out again. Any advise? > > Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a > Apache::AuthCookie is version 2.011 > I'm also using Embperl v1.2.1 > > from .htaccess in the protected directories > > AuthType Apache::AuthCookieHandler > AuthName Apollo > PerlAuthenHandler Apache::AuthCookieHandler->authenticate > PerlAuthzHandler Apache::AuthCookieHandler->authorize > require valid-user > > from httpd.conf > > PerlModule Apache::AuthCookieHandler > PerlSetVar ApolloPath / > PerlSetVar ApolloLoginScript /Protected/Login/login.epl > > # This is the action of the login.epl script above. > > AuthType Apache::AuthCookieHandler > AuthName Apollo > SetHandler perl-script > PerlHandler Apache::AuthCookieHandler->login > > > Thanks, > John > > -- > John Walstra CNET Networks > Senior Software Developer, Jack Of All Trades300 Park Blvd, Suite 105 > mailto:[EMAIL PROTECTED]Itasca, IL 60143-4914 > Phone: 630.438.7000 x1304Fax: 630.775.0555 -- __ JR Mayberry e-Vend.net Corporation Programmer and Systems Administrator(888) 427-8743 x226 tel [EMAIL PROTECTED]http://www.e-vend.net The information in this message (including attachments) is confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ***
Re: Apache::AuthCookie and SSL
might wanna modify the source to set the domain to .yourdomain.com, as its probably now being set as secure.yourdomain.com or www.yourdomain.com i have the same setup here, it works fine.. John Walstra wrote: > > I'm having the problem with being logged out then I switch to a secure > document. I have to log back in to get to the page. And when I go from a SSL > page to a plain page it logs me out again. Any advise? > > Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a > Apache::AuthCookie is version 2.011 > I'm also using Embperl v1.2.1 > > from .htaccess in the protected directories > > AuthType Apache::AuthCookieHandler > AuthName Apollo > PerlAuthenHandler Apache::AuthCookieHandler->authenticate > PerlAuthzHandler Apache::AuthCookieHandler->authorize > require valid-user > > from httpd.conf > > PerlModule Apache::AuthCookieHandler > PerlSetVar ApolloPath / > PerlSetVar ApolloLoginScript /Protected/Login/login.epl > > # This is the action of the login.epl script above. > > AuthType Apache::AuthCookieHandler > AuthName Apollo > SetHandler perl-script > PerlHandler Apache::AuthCookieHandler->login > > > Thanks, > John > > -- > John Walstra CNET Networks > Senior Software Developer, Jack Of All Trades300 Park Blvd, Suite 105 > mailto:[EMAIL PROTECTED]Itasca, IL 60143-4914 > Phone: 630.438.7000 x1304Fax: 630.775.0555 -- __ JR Mayberry e-Vend.net Corporation Programmer and Systems Administrator(888) 427-8743 x226 tel [EMAIL PROTECTED]http://www.e-vend.net The information in this message (including attachments) is confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ***
Apache::AuthCookie and SSL
I'm having the problem with being logged out then I switch to a secure document. I have to log back in to get to the page. And when I go from a SSL page to a plain page it logs me out again. Any advise? Apache/1.3.12 (Unix) mod_perl/1.24 mod_ssl/2.6.6 OpenSSL/0.9.5a Apache::AuthCookie is version 2.011 I'm also using Embperl v1.2.1 from .htaccess in the protected directories AuthType Apache::AuthCookieHandler AuthName Apollo PerlAuthenHandler Apache::AuthCookieHandler->authenticate PerlAuthzHandler Apache::AuthCookieHandler->authorize require valid-user from httpd.conf PerlModule Apache::AuthCookieHandler PerlSetVar ApolloPath / PerlSetVar ApolloLoginScript /Protected/Login/login.epl # This is the action of the login.epl script above. AuthType Apache::AuthCookieHandler AuthName Apollo SetHandler perl-script PerlHandler Apache::AuthCookieHandler->login Thanks, John -- John Walstra CNET Networks Senior Software Developer, Jack Of All Trades300 Park Blvd, Suite 105 mailto:[EMAIL PROTECTED]Itasca, IL 60143-4914 Phone: 630.438.7000 x1304Fax: 630.775.0555
Apache::AuthCookie now on SourceForge
Hi all, I have just created a SourceForge project for AuthCookie. If you are interested, you can access the project at http://sourceforge.net/projects/ap-authcookie/ . All previous releases are there, and I have imported the CVS tree too. Moving the project to SourceForge gives several benefits. First, interested developers can access the distribution via anonymous CVS. Second, the bug tracking tools & task list seem like they'll help organize my development and help let other people know the current statuses of project details. And third, it opens the possibility of having other developers work on the project. For some time now, I haven't had enough time to synthesize all the various requests/contributions/questions people have contacted me about. I've been considering finding a new person to be the shepherd of AuthCookie, but for the time being I think I'll hold off on that and remain in charge. I would like to make the development a bit more open though, because lately I've been a bit of a communication black-hole and the project has stagnated because of it. If you have any interest in being a developer or otherwise influencing the direction of the module, please contact me. I'm not sure whether I'm ready to coördinate the activity of lots of people, but I suspect perhaps only 1 or 2 people will be interested anyway. Although SourceForge provides discussion tools, I would like the mod_perl list to remain the main point of contact for AuthCookie support & discussion. It's possible that in the future we'll want to make a development list or something, but for now let's hold off. Pretty soon I will probably move Apache::Filter development to SourceForge too. Thanks for the time. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Apache::AuthCookie question
Hi, This may not be anything specific to Apache::AuthCookie. So sorry for the off-topic question. I have been able to get Apache::AuthCookie to work for me on directories other than the URL root . What happens when I do that is that the images in the script invoked by the LOGIN location do not come up. Basically, what I want to do is: [ .. AuthCookie Stuff ..] require valid-user [ ..force no authentication/authorization here ..] Thanks, Liz __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
ANNOUNCE: Apache::AuthCookie 2.011
Hi, The URL http://mathforum.com/~ken/modules/archive/Apache-AuthCookie-2.011.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Apache-AuthCookie-2.011.tar.gz size: 18530 bytes md5: b4617ac3ed237e2ae5123e9c7756fc82 This release follows right on the heels of 2.010. Here's the change: Version: 2.011 Date: 2000/06/17 08:01:19 Several people have requested a mechanism for the login script to be able to tell the difference between a failed login and a first attempt at a login. Typically one can figure this out by whether a cookie has been sent or not, so I've put some information to that effect in $r->prev->subprocess_env(). See the login script docs for specifics. I also cleaned up the documentation for the login script. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
ANNOUNCE: Apache::AuthCookie 2.010
Hi, The URL http://mathforum.com/~ken/modules/archive/Apache-AuthCookie-2.010.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Apache-AuthCookie-2.010.tar.gz size: 17587 bytes md5: 664e97ccba483b2a2462ad0ab919b33d There are lots of changes from 2.007, which was the previous release. The intermediate releases didn't go to CPAN, even though I was confused and thought they did. Sorry for the delay, hope some of this stuff is worth it! Version: 2.010 Date: 2000/06/17 01:37:16 (merged changes from sub-releases into main CVS branch. Been living in CVS hell. My CVS-hubris got the better of me, tried to do things with tags & soforth and wound up severely confused. Thus the version numbers jumped a bit.) Made some minor documentation updates. Version: 2.008 Date: 2000/06/14 15:36:12 Instead of replacing the Set-Cookie header when we set the cookie, add to it. This means we won't clobber other folks' unrelated cookies when we set ours. It also means you need at least mod_perl version 1.24 (I think). [[EMAIL PROTECTED] (Robert Locke)] Version: 2.007.002.001 Date: 2000/05/14 18:06:30 Added a PerlSetVar *Cache parameter that you can set to a true value to allow cacheing. Also removed cache control from regular requests - cacheing still happens on login & logout. [[EMAIL PROTECTED] (Alan Sparks) and [EMAIL PROTECTED] (Drew Taylor)] Split off the login-form-displaying code into its own method, called login_form(). Can be overridden in subclasses. The default method uses $r->custom_response() to display the login. [[EMAIL PROTECTED] (Gerald Richter)] Added documentation for the send_cookie() method. Version: 2.007.001.001 Date: 2000/04/29 20:03:51 Created the send_cookie() method, which just creates the cookie and calls $r->err_header_out to send it to the browser. It is occasionally useful to override this method if you need to change the value of the cookie before sending it out (for instance, to update a timestamp). [[EMAIL PROTECTED] (Michael J Schout)] Changed the _cookie_string() method to cookie_string(). Added a PerlSetVar configuration directive "{YourAuth}Secure" which will secure cookies (i.e. only send them over a secure connection). [[EMAIL PROTECTED] (Michael J Schout)] ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Apache::AuthCookie
Having problem with the above, anyone any idea It doesn't seem to create the cookie I added the log_error above err_header_out in login() $r->log_error("SET COOKIE " . $self->_cookie_string($r, "$auth_type\_$auth_name", $ses_key)) if ($debug >= 2); $r->err_header_out("Set-Cookie" => $self->_cookie_string($r, "$auth_type\_$auth_name", $ses_key)); errorlog entry SET COOKIE Sample::AuthCookieHandler_Tas=fd3388f426a210cba2a1d6307345c56a; path=/; domain=hp7; [Tue Jun 13 18:05:11 2000] [error] ses_key_cookie i.e it doesn't seem to have set the cookie?? Any ideas would be greatly appreciated!! Thanks John This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it.
Re: Fine-grained authorization w. Apache::AuthCookie
At 11:26 AM 5/23/00 -0500, James G Smith wrote: >Ken Miller <[EMAIL PROTECTED]> wrote: >>I'm using Apache::AuthCookie for general authentication/authorization for a >>site I'm working on. However, there's a requirement for fine-grained >>authorization down to the page level - a user may have access to most pages >>in a directory, but be disalllowed access to a single page. Note that the >>pages in question are in a single directory. >Short answer is `yes, it can be done.' Next comes the question of how... > >What we don't want is the login page being presented if a valid user is >accessing the page. What you could do is return the proper error status when >the person is unauthorized, and then in the error document check to see if the >person has authenticated or not (basically, a valid $ENV{REMOTE_USER} or >equivalent). If so, then throw up a page explaining that they do not have >proper permissions. Otherwise, present the login page. > >I'm not familiar with Apache::AuthCookie enough (or haven't looked at it >recently enough) to know exactly how the above would be accomplished, or how >Apache::AuthCookie would interact with the ErrorDocument, but it would seem >the cleanest way to me. Well, it appears that I has having a bit of a brain cramp. AuthCookie already behaves this way, so I have idea what I was doing to make it always jump back to the login page. I tried it again, and sure enough I got the 403 error page when already logged in. If I'm not logged in, I get the login page. All I have to do now is (I think) extend the authz handler methods to make sure that the user not only has general access to the uri directory, but to the specific uri as well. Sorry for the wasted bandwidth. Thanks. Cheers! -klm. --- Ken Miller, Consultant Shetland Software Services Inc.
Re: Fine-grained authorization w. Apache::AuthCookie
Ken Miller <[EMAIL PROTECTED]> wrote: >I'm using Apache::AuthCookie for general authentication/authorization for a >site I'm working on. However, there's a requirement for fine-grained >authorization down to the page level - a user may have access to most pages >in a directory, but be disalllowed access to a single page. Note that the >pages in question are in a single directory. > >What I don't want is to have the user tossed to a login page if they try to >access a page for which they have no access, which is what AuthCookie >currently does. > >I thought about chaining an additional authorization handler, but that >won't work since if the first one in the chain approves access, then the >rest won't be called. I think that AuthCookie should come first, since it >verifies that the user has actually logged in. So, if the user passes >muster on the first stage of authorization (general access to directory) >then any other handlers in the chain won't be called. Or is there a way to >override this behaviour? > >What's the best way to do this? I can always stuff some code into my main >handler, but that's ugly. Short answer is `yes, it can be done.' Next comes the question of how... What we don't want is the login page being presented if a valid user is accessing the page. What you could do is return the proper error status when the person is unauthorized, and then in the error document check to see if the person has authenticated or not (basically, a valid $ENV{REMOTE_USER} or equivalent). If so, then throw up a page explaining that they do not have proper permissions. Otherwise, present the login page. I'm not familiar with Apache::AuthCookie enough (or haven't looked at it recently enough) to know exactly how the above would be accomplished, or how Apache::AuthCookie would interact with the ErrorDocument, but it would seem the cleanest way to me. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Fine-grained authorization w. Apache::AuthCookie
I'm using Apache::AuthCookie for general authentication/authorization for a site I'm working on. However, there's a requirement for fine-grained authorization down to the page level - a user may have access to most pages in a directory, but be disalllowed access to a single page. Note that the pages in question are in a single directory. What I don't want is to have the user tossed to a login page if they try to access a page for which they have no access, which is what AuthCookie currently does. I thought about chaining an additional authorization handler, but that won't work since if the first one in the chain approves access, then the rest won't be called. I think that AuthCookie should come first, since it verifies that the user has actually logged in. So, if the user passes muster on the first stage of authorization (general access to directory) then any other handlers in the chain won't be called. Or is there a way to override this behaviour? What's the best way to do this? I can always stuff some code into my main handler, but that's ugly. Thanks. Cheers! -klm. --- Ken Miller, Consultant Shetland Software Services Inc.
RE: ANNOUNCE: Apache::AuthCookie 2.007
[EMAIL PROTECTED] (Gerald Richter) wrote: >Hi Ken, > >the patch I send you for overwriting the login_form seems not to be in >2.007. > >Are there any reason for this or did you just forget it? Hi Gerald, Actually, neither - it's just that I haven't gotten to it yet. The changes I put in 2.007 come from requests/patches people submitted before you. =) Your patch looks good, but I haven't had a chance to look closely. I hope to get it in there soon in some form.
RE: ANNOUNCE: Apache::AuthCookie 2.007
Hi Ken, the patch I send you for overwriting the login_form seems not to be in 2.007. Are there any reason for this or did you just forget 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Help needed with Apache::AuthCookie 2.007
[EMAIL PROTECTED] (Kenneth Frankel) wrote: >Could someone provide a good FAQ or example of how to impliment this >thing? The package documentation's "just copy the test script" example I'm >sure is a great time-saver for the author but when one has problems it's >really a pain with all the unrelated testing code. It's not a time-saver for me - the module is fully documented (344 lines of docs), AND there's a test suite. If you find that some information is missing from the documentation, please tell me. The docs never advise to "just copy" anything, they merely point out that the test suite is often a useful place to find code that works. Everything should also be fully documented. Simply copying the example is actually a *bad* idea since it'll probably mean one won't really understand how things work. Not good for an auth system. >I'm having problems and it's probably my mod-perl configuration but I >can't sort out what's wrong comparing to the test-script non-example. >If someone could provide their setup without the "WhatEver" and >"Sample" namings it'd be really appreciated! What difference would that make? But if you want it, I'll mail you mine off-list. >Thanks, >Kenneth > >P.S. If you need to fix what's wrong (thanks, man!), the errors are >configuration error: couldn't check user. No user file?: /bqbin/gui.pl That error isn't coming from Apache::AuthCookie, it's coming from Apache (or its basic auth module). For one reason or another, you still seem to be configured for basic auth. Are you sure you have the AuthType and AuthName parameters set correctly? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::AuthCookie or Apache::AuthDBI or Apache::???
> "KF" == Kenneth Frankel <[EMAIL PROTECTED]> writes: KF> What's the best way to authenticate users? I have a site where the entire KF> site is to be protected. I want to log users in at the front of the web For a site whose contents are entirely protected, I'd use basic auth with a cookie override. That's what I've done in the past. Neither of these require perl or mod_perl, though. See the apache module registry at www.apache.org for references to my mod_auth_cookie which tricks Apache into converting a cookie into a basic auth header. How you set the cookie is up to you... How you authenticate depends mostly on your needs of maintaining the database. I've used flat files with htpasswd, dbm files with htpasswd and my own home brew scripts, and MySQL tables with my own scripts. None of these require mod_perl, either, but you can use mod_perl based versions of the necessary authentication modules.
Apache::AuthCookie or Apache::AuthDBI or Apache::???
What's the best way to authenticate users? I have a site where the entire site is to be protected. I want to log users in at the front of the web site, and keep them logged in as they travel around. I was trying to get AuthCookie to work but haven't been successful so far. Should I continue down this route? Is Apache::Session + AuthBasic better? Or is AuthDBI? I have a mysql database handy. What's the most popular Auth method nowadays? Is there a popularity/usage chart compiled anywhere? Thanks in advance! Kenneth
Help needed with Apache::AuthCookie 2.007
Could someone provide a good FAQ or example of how to impliment this thing? The package documentation's "just copy the test script" example I'm sure is a great time-saver for the author but when one has problems it's really a pain with all the unrelated testing code. I'm having problems and it's probably my mod-perl configuration but I can't sort out what's wrong comparing to the test-script non-example. If someone could provide their setup without the "WhatEver" and "Sample" namings it'd be really appreciated! Thanks, Kenneth P.S. If you need to fix what's wrong (thanks, man!), the errors are configuration error: couldn't check user. No user file?: /bqbin/gui.pl
ANNOUNCE: Apache::AuthCookie 2.007
The URL http://forum.swarthmore.edu/~ken/modules/archive/Apache-AuthCookie-2.007.tar.gz has entered CPAN as file: $CPAN/authors/id/KWILLIAMS/Apache-AuthCookie-2.007.tar.gz size: 16364 bytes md5: 1a2a45007123e8583467668297ebd767 Version: 2.007 Date: 2000/04/15 15:27:02 If the browser sends a cookie but it's not one related to our authentication, we formerly sent a blank cookie to the authentication methods. Now we act as if no cookie was sent. [[EMAIL PROTECTED] (Alan Sparks)] Fixed a server error that occurred when a certain user was required, but a different valid user was logged in. [[EMAIL PROTECTED] (Eduardo Fujii)] Added a couple more debug statements that can help figure out what's happening when your auth isn't working. Improved some of the docs. Added some tricks to Makefile.PL to make my life easier. Changed the action of the example login forms from LOGIN to /LOGIN. [[EMAIL PROTECTED] (Michael)] ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: PATCH for Apache::AuthCookie to overwrite the login_form display
[EMAIL PROTECTED] (Gerald Richter) wrote: >Hi Ken, > >I use your Apache::AuthCookie in an application where the way to display the >login form via the custon_response does not fit my needs. Instead the normal >ContentHandler has to display th login form. I have made a simple patch to >Apache::AuthCookie that splits up the call to custom_response in an separate >method, so I am able to overwrite it. Thanks Gerald, I'll roll it in. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
PATCH for Apache::AuthCookie to overwrite the login_form display
Hi Ken, I use your Apache::AuthCookie in an application where the way to display the login form via the custon_response does not fit my needs. Instead the normal ContentHandler has to display th login form. I have made a simple patch to Apache::AuthCookie that splits up the call to custom_response in an separate method, so I am able to overwrite it. I append you the patch (against 2.006) and hope you will include it in your next release 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 - Apache-AuthCookie-2.006-patch
ANNOUNCE: Apache::AuthCookie 2.001
Hi, The URL http://forum.swarthmore.edu/~ken/modules/archive/Apache-AuthCookie-2.001.tar.gz has entered CPAN as file: $CPAN/authors/id/KWILLIAMS/Apache-AuthCookie-2.001.tar.gz size: 14968 bytes md5: 252ea4ec539f0c303ae552a4e25588d5 - The login forms may now use the POST method instead of the GET method. This is a big deal, because with GET the user's credentials get logged to access logs, they remain in the user's browser history, and so on. Thanks to [EMAIL PROTECTED] (Eric Cholet) for the patch and prodding. - There is now a proper test suite, which will fire up an httpd and make requests of it. The test code is adapted from Eric's old example (eg/) suite. - I've added a logout() method to help unset cookies. The example logout.pl now uses logout(). Thanks to Aaron Ross ([EMAIL PROTECTED]). These are 3 pretty important additions. Let me know how they pan out. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
ANNOUNCE: Apache::AuthCookie v2.0
Hi, here's the eagerly-awaited announcement: ** * The URL * * http://mathforum.com/~ken/modules/archive/Apache-AuthCookie-2.000.tar.gz * * has entered CPAN as * * file: $CPAN/authors/id/KWILLIAMS/Apache-AuthCookie-2.000.tar.gz * size: 12760 bytes *md5: e943bebd35b8151d0d10aa039b67fb4a * * Changed in version 2.0: * * - Now owned by Ken Williams ([EMAIL PROTECTED]) * * - Created authenticate() and authorize() methods to replace authen() * and authz(). authen() and authz() are now deprecated and will * disappear in a later version. * * - AuthType can now contain colons [[EMAIL PROTECTED] (Adi)] * * - Nonexistent method calls (via 'require' directive) are no longer * shielded in authorization stage - if it fails it fails, and you * get a server error. * * - Multiple 'require' directives should work now - previously only * the first directive was respected. ** I've got a couple other changes I want to make soon, but I wanted to get version 2 out the door. Let me know how it goes. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::AuthCookie with multiple 'require' directives?
'c' code in mod_auth seems to work similar as the perl code below. - snip - for (x = 0; x < reqs_arr->nelts; x++) { if (!(reqs[x].method_mask & (1 << m))) continue; method_restricted = 1; t = reqs[x].requirement; w = ap_getword_white(r->pool, &t); if (!strcmp(w, "valid-user")) return OK; if (!strcmp(w, "user")) { while (t[0]) { w = ap_getword_conf(r->pool, &t); if (!strcmp(user, w)) return OK; } } else if (!strcmp(w, "group")) { if (!grpstatus) return DECLINED;/* DBM group? Something else? */ while (t[0]) { w = ap_getword_conf(r->pool, &t); if (ap_table_get(grpstatus, w)) return OK; } } else if (sec->auth_authoritative) { /* if we aren't authoritative, any require directive could be * valid even if we don't grok it. However, if we are * authoritative, we can warn the user they did something wrong. * That something could be a missing "AuthAuthoritative off", but * more likely is a typo in the require directive. */ ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r, "access to %s failed, reason: unknown require directive:" "\"%s\"", r->uri, reqs[x].requirement); } } if (!method_restricted) return OK; if (!(sec->auth_authoritative)) return DECLINED; ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r, "access to %s failed, reason: user %s not allowed access", r->uri, user); ap_note_basic_auth_failure(r); return AUTH_REQUIRED; } - snip - cliff rayman genwax.com Ken Williams wrote: > Hi, > > I'm looking at the AuthCookie code, getting ready to release a new version to > CPAN. It looks to me like currently only the first 'require' directive will be > processed and obeyed. Here's the code from the old authz(): > > > foreach $reqs (@$reqs_arr) { > ($requirement, $args) = split /\s+/, $reqs->{requirement}, 2; > $args = "" unless defined $args; > $r->log_error("requirement := $requirement, $args") if ($debug >= 2); > > if ($requirement eq "valid-user") { > return OK; > } elsif ($requirement eq "user") { > return OK if ($args =~ m/\b$user\b/); > } else { > my $ret_val = $auth_type->$requirement($r, $args); > $r->log_error("$auth_type->$requirement returned $ret_val") > if $debug >= 3; > return OK if $ret_val == OK; > } > $restricted++; > } > > return OK unless $restricted; > return FORBIDDEN; > > > Is anyone actually using this with multiple "require' directives? Or would > anyone like to? > > ------ > Ken Williams Last Bastion of Euclidity > [EMAIL PROTECTED]The Math Forum
Re: Apache::AuthCookie with multiple 'require' directives?
looks to me like it is using an OR approach. first successful match returns OK. Ken Williams wrote: > Hi, > > I'm looking at the AuthCookie code, getting ready to release a new version to > CPAN. It looks to me like currently only the first 'require' directive will be > processed and obeyed. Here's the code from the old authz(): > > > foreach $reqs (@$reqs_arr) { > ($requirement, $args) = split /\s+/, $reqs->{requirement}, 2; > $args = "" unless defined $args; > $r->log_error("requirement := $requirement, $args") if ($debug >= 2); > > if ($requirement eq "valid-user") { > return OK; > } elsif ($requirement eq "user") { > return OK if ($args =~ m/\b$user\b/); > } else { > my $ret_val = $auth_type->$requirement($r, $args); > $r->log_error("$auth_type->$requirement returned $ret_val") > if $debug >= 3; > return OK if $ret_val == OK; > } > $restricted++; > } > > return OK unless $restricted; > return FORBIDDEN; > > > Is anyone actually using this with multiple "require' directives? Or would > anyone like to? > > ------ > Ken Williams Last Bastion of Euclidity > [EMAIL PROTECTED]The Math Forum
Apache::AuthCookie with multiple 'require' directives?
Hi, I'm looking at the AuthCookie code, getting ready to release a new version to CPAN. It looks to me like currently only the first 'require' directive will be processed and obeyed. Here's the code from the old authz(): foreach $reqs (@$reqs_arr) { ($requirement, $args) = split /\s+/, $reqs->{requirement}, 2; $args = "" unless defined $args; $r->log_error("requirement := $requirement, $args") if ($debug >= 2); if ($requirement eq "valid-user") { return OK; } elsif ($requirement eq "user") { return OK if ($args =~ m/\b$user\b/); } else { my $ret_val = $auth_type->$requirement($r, $args); $r->log_error("$auth_type->$requirement returned $ret_val") if $debug >= 3; return OK if $ret_val == OK; } $restricted++; } return OK unless $restricted; return FORBIDDEN; Is anyone actually using this with multiple "require' directives? Or would anyone like to? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::AuthCookie takeover?
On Tue, 25 Jan 2000, Ken Williams wrote: > > Can someone set the maintainer of Apache::AuthCookie to be me? patch below :) thanks Ken!! diff -u -u -r1.63 apache-modlist.html --- apache-modlist.html 1999/11/24 02:40:01 1.63 +++ apache-modlist.html 2000/01/27 05:19:27 @@ -114,7 +114,7 @@ * PerlAuthenHandler's AuthAnybdpfAuthenticate with any username/password MPB AuthenCachebmpfCache authentication credentialsJBODNAR -AuthCookie bdpOAuthen + Authz via cookies EBARTLEY +AuthCookie bdpOAuthen + Authz via cookies KWILLIAM AuthenDBI bmpOAuthenticate via Perl's DBI MERGL AuthExpire i Expire Basic auth credentials DOUGM AuthenGSS cdpfGeneric Security Service (RFC 2078) DOUGM
Re: Apache::AuthCookie takeover?
[EMAIL PROTECTED] (Ask Bjoern Hansen) wrote: >On Sat, 22 Jan 2000, Ken Williams wrote: > >> * make a new module with a new name, since some of my changes have changed >> the interface, or >> * usurp the Apache::AuthCookie module and provide a clear >> stepwise migration >> path? Doug said he'd be willing to make me the maintainer. > >The last. Much better than leaving a module around not to be maintained. This seems to be the consensus. I'll start myself a CVS project so I can start keeping track of my changes. =) Can someone set the maintainer of Apache::AuthCookie to be me? >If the interface haven't changed too much you might even be able to do >some backwards compatibility thing. Yeah, I think I'll change the names of a couple methods, make those the new interface, and keep the old methods around for a couple of releases. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::AuthCookie takeover?
On Sat, 22 Jan 2000, Ken Williams wrote: > * make a new module with a new name, since some of my changes have changed > the interface, or > * usurp the Apache::AuthCookie module and provide a clear stepwise migration > path? Doug said he'd be willing to make me the maintainer. The last. Much better than leaving a module around not to be maintained. If the interface haven't changed too much you might even be able to do some backwards compatibility thing. - ask -- ask bjoern hansen - <http://www.netcetera.dk/~ask/> more than 60M impressions per day, <http://valueclick.com>
Re: Apache::AuthCookie takeover?
I've been using Apache::AuthCookie, and it's great, but just from playing with it briefly I see some apparent issues. For one thing I didn't find an obvious way to delete a session from the database. It relies on the browser to delete the session key cookie. Right now, my MSIE is not deleting that cookie for some reason, while Netscape is, so I can't "log out" using MSIE. I don't know if anyone else has noticed this or if there's some easy way to fix it, but I want to use this in a production environment. Unless someone else is working on this, I'll have to fix it somehow, whether or not it's code anyone else would dare run on their server. I'm also wondering how possible it would be to add an option to use the browser's "basic" login dialog box instead of having to create an HTML page for it. It's something else I'm thinking of trying to do, but again I'd like to know if anyone else is either working on it or knows some reason not to. This module seems to be a tremendously useful tool for any site that needs authentication. Its next maintainer will earn my gratitude and whatever asistance I'm capable of. Adam On Jan 24 Bruce W. Hoylman wrote >>>>> "Ken" == Ken Williams [EMAIL PROTECTED] writes: >> make a new module with a new name, since some of my changes have >> changed the interface, or usurp the Apache::AuthCookie module and >> provide a clear stepwise migration path? Doug said he'd be willing >> to make me the maintainer. My vote is for 'usurption'. I use this module alot and I too have seen the need for changes. I think it best to go forward with the current module and namespace conventions for continuity at my site. You do good work, Ken. I look forward to seeing what you have done with this very useful module. Peace.
Re: Apache::AuthCookie takeover?
>>>>> "Ken" == Ken Williams <[EMAIL PROTECTED]> writes: >> make a new module with a new name, since some of my changes have >> changed the interface, or usurp the Apache::AuthCookie module and >> provide a clear stepwise migration path? Doug said he'd be willing >> to make me the maintainer. My vote is for 'usurption'. I use this module alot and I too have seen the need for changes. I think it best to go forward with the current module and namespace conventions for continuity at my site. You do good work, Ken. I look forward to seeing what you have done with this very useful module. Peace.
Re: Apache::AuthCookie takeover?
Hi there, On Sat, 22 Jan 2000, Ken Williams wrote: > should I > > * make a new module with a new name, since some of my changes have changed > the interface, or > * usurp the Apache::AuthCookie module and provide a clear stepwise migration > path? Doug said he'd be willing to make me the maintainer. I think the last thing we need is *another* AuthModuleName. Just my 0.02p worth. 73, Ged.
Apache::AuthCookie takeover?
Hi, Apparently Eric Bartley isn't maintaining Apache::AuthCookie anymore. I've made a bunch of improvements to its functionality, and I'd like to commit those to CPAN. Before I do that, I thought I'd throw the question out there: should I * make a new module with a new name, since some of my changes have changed the interface, or * usurp the Apache::AuthCookie module and provide a clear stepwise migration path? Doug said he'd be willing to make me the maintainer. An explanation of my changes can be seen at http://forum.swarthmore.edu/epigone/modperl/gonplingoo If option 1 is preferred, we need to come up with a new name. As I see it, the name should be an "Apache::Auth*" name. The key features of the module are that it manages the setting & deleting of cookies for you, and that it re-routes the user to login/logout pages when appropriate. Apache::AuthCookieTicket? Apache::AuthTicket? (Does this exist?) ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: possible patch for Apache::AuthCookie
[EMAIL PROTECTED] (Robert Locke) wrote: >Below is a proposed patch to AuthCookie.pm that I believe solves this >problem. Basically, I replaced each occurrence of the above with: >$r->err_headers_out->add("Set-Cookie" => ... I think you've got the patch backwards. >PS. Who's the current maintainer of Apache::AuthCookie? I seem to >remember reading somehwere that it is no longer Eric Bartley. Yeah, it's not. I've been toying with the code and improving it, but my improvements make it non-backward-compatible. So I might need to change the name and make myself the owner of the new version. Not that I have a lot of time... >-- >diff AuthCookie.pm* >112c112 >< $r->err_headers_out->add("Set-Cookie" => $auth_type . "_" . >--- >> $r->err_header_out("Set-Cookie" => $auth_type . "_" . >114c114 >< $r->log_error("set_cookie " . $r->err_headers_out->add("Set-Cookie")) >--- >> $r->log_error("set_cookie " . $r->err_header_out("Set-Cookie")) >142c142 >< $r->err_headers_out->add("Set-Cookie" => $auth_type . "_" . $auth_name . >--- >> $r->err_header_out("Set-Cookie" => $auth_type . "_" . $auth_name . >145c145 >< $r->log_error("set_cookie " . $r->err_headers_out->add("Set-Cookie")) >--- >> $r->log_error("set_cookie " . $r->err_header_out("Set-Cookie")) >-- > ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
possible patch for Apache::AuthCookie
Hi all, Currently, Apache::AuthCookie uses: $r->err_header_out("Set-Cookie" => ... to set its cookie. However, if you're authentication or authorization routines also sets a cookie, then it will get overwritten by the above code. Below is a proposed patch to AuthCookie.pm that I believe solves this problem. Basically, I replaced each occurrence of the above with: $r->err_headers_out->add("Set-Cookie" => ... This assumes that you have Apache::Table compiled in. The corresponding code to read in the cookies (using err_header_in) is not a problem since it seems that browsers return all cookies destined for a particular domain/path in a single ";" delimited HTTP header field. Thanks! Rob PS. Who's the current maintainer of Apache::AuthCookie? I seem to remember reading somehwere that it is no longer Eric Bartley. -- diff AuthCookie.pm* 112c112 < $r->err_headers_out->add("Set-Cookie" => $auth_type . "_" . --- > $r->err_header_out("Set-Cookie" => $auth_type . "_" . 114c114 < $r->log_error("set_cookie " . $r->err_headers_out->add("Set-Cookie")) --- > $r->log_error("set_cookie " . $r->err_header_out("Set-Cookie")) 142c142 < $r->err_headers_out->add("Set-Cookie" => $auth_type . "_" . $auth_name . --- > $r->err_header_out("Set-Cookie" => $auth_type . "_" . $auth_name . 145c145 < $r->log_error("set_cookie " . $r->err_headers_out->add("Set-Cookie")) --- > $r->log_error("set_cookie " . $r->err_header_out("Set-Cookie")) --
Re: Patch for Apache::AuthCookie
>>>>> "Spidaman" == Spidaman The Defenestrator <[EMAIL PROTECTED]> writes: Spidaman> I've been messing around with some wacky PerlAccessHandler Spidaman> and PerlAuthenHandler code lately, if Apache::AuthCookie Spidaman> is orphaned I might want to fix it up. Last I looked, Spidaman> it's tests choked on "Undefined subroutine Spidaman> &Apache::perl_hook" ...IIRC that means it's not current. Spidaman> Is anybody using it in production with recent mod_perl's?? Yes, I am using the CPAN version of Apache-AuthCookie-1.4 with mod_perl 1.2101, apache 1.3.10dev, both as of 19991006, although AuthCookie was compiled and installed with earlier versions of mod_perl and Apache. Looking back at the installation source which I keep around for posterity and attempting the standard 'perl Makefile.PL; make test', I now get the message: Undefined subroutine &Apache::perl_hook called at /u/bhoylma/lib/perl5/site_perl/5.005/sun4-solaris/mod_perl.pm line 28. This does not appear to effect the run quality of the package as it is working flawlessly, although I would not be able to get it to pass its test cases with my current configuration. No worries, right? Peace.
Re: Patch for Apache::AuthCookie
Yeah, I'm using it in production, it works fine. You just can't test compiling it from the command line, that's when you get the perl_hook error. [EMAIL PROTECTED] (Spidaman The Defenestrator) wrote: > >I've been messing around with some wacky PerlAccessHandler and >PerlAuthenHandler code lately, if Apache::AuthCookie is orphaned I might >want to fix it up. Last I looked, it's tests choked on "Undefined >subroutine &Apache::perl_hook" ...IIRC that means it's not current. Is >anybody using it in production with recent mod_perl's?? > >Meanwhile, back at the ranch... > >> Hi folks, >> >> I haven't gotten any response about this. My email to Eric Bartley >> (the author of Apache::AuthCookie) bounced - does anyone know how to >> contact him, or whether there's a new maintainer? >> >> If we can't find him, I suppose we should either make a new module >> for this (Apache::CookieAuth?) or find a new maintainer for >> AuthCookie. >> >> >> [EMAIL PROTECTED] (Ken Williams) wrote: >> >Hi mod_perl-ers, >> > >> >I've been working with the Apache::AuthCookie module, and have made a >> >couple of modifications that make it more flexible. As an added >> >benefit, the code is now shorter and simpler. =) I hereby submit the >> >code for discussion and possible adoption by Eric. Patch attached. >> > >> >The motivation for this was that I wanted users to be able to access >> >certain documents whether they're logged in or not. If they're logged >> >in, they should get a customized version of the document (packages like >> >HTML::Mason make this easy), and if they're not, they get a generic >> >version. This required two changes: >> > >> > - Apache::AuthCookie should be able to recognize whether a user is logged >> > in, *even for unprotected documents*. >> > >> > - Since a user can access a document regardless of whether he/she is >> > logged in, and since the user should be able to log in at any time, the >> > login procedure should be trigerrable by some means other than simply >> > accessing a protected document. >> > >> >The key change is that there's now a URL (I've called it LOGIN) and >> >corresponding method (Apache::AuthCookie->login()) that handles a >> >user's initial login. After login, the user is redirected to the page >> >they requested. This means that the authen() method doesn't have to >> >implement such complicated logic anymore - if the user sent a cookie, >> >check its validity. If not, redirect to the login form. That meant I >> >could rip out a lot of the code from the authen() method. >> > >> >There's also a new recognize_user() method which checks to see whether >> >a valid authentication cookie has been sent, and if so, sets >> >$r->connection->user. >> > >> > >> >As a bonus side-effect, AuthCookie can now authenticate even when the >> >requested page URL has a non-empty query string (this has been a >> >limitation of AuthCookie). This is because the redirection URL is now >> >simply sent in the login form as a hidden field, so it can contain >> >whatever query information it wants. >> > >> > >> >It's important to note that these changes are not fully backward-compatible >> >with previous versions. Some modifications will be required to adopters' >> >..htaccess files and login forms. Here's what mine look like. The login form >> >can be on any page, allowing the user to log in at any time: >> > >> > >> > >> > >> > >> > username: >> > password: >> > >> > >> > >> >My .htaccess file (in a /listeners/ directory) is as follows. MMAuth is a >> >subclass of Apache::AuthCookie, implementing the authen_cred() and >> >authen_ses_key() methods. >> > >> > >> > AuthType MMAuth >> > AuthName Listener >> > PerlSetVar ListenerPath /listeners/ >> > PerlSetVar ListenerLoginScript /listeners/login.pl >> > PerlSetVar MMSessionExpiration 480 >> > PerlFixupHandler MMAuth->recognize_user >> > >> > >> > SetHandler perl-script >> > PerlHandler MMAuth->login >> > >> > >> > >> > PerlAuthenHandler MMAuth->authen >> > PerlA
Re: Patch for Apache::AuthCookie
I've been messing around with some wacky PerlAccessHandler and PerlAuthenHandler code lately, if Apache::AuthCookie is orphaned I might want to fix it up. Last I looked, it's tests choked on "Undefined subroutine &Apache::perl_hook" ...IIRC that means it's not current. Is anybody using it in production with recent mod_perl's?? Meanwhile, back at the ranch... > Hi folks, > > I haven't gotten any response about this. My email to Eric Bartley (the author > of Apache::AuthCookie) bounced - does anyone know how to contact him, or > whether there's a new maintainer? > > If we can't find him, I suppose we should either make a new module for this > (Apache::CookieAuth?) or find a new maintainer for AuthCookie. > > > [EMAIL PROTECTED] (Ken Williams) wrote: > >Hi mod_perl-ers, > > > >I've been working with the Apache::AuthCookie module, and have made a > >couple of modifications that make it more flexible. As an added > >benefit, the code is now shorter and simpler. =) I hereby submit the > >code for discussion and possible adoption by Eric. Patch attached. > > > >The motivation for this was that I wanted users to be able to access > >certain documents whether they're logged in or not. If they're logged > >in, they should get a customized version of the document (packages like > >HTML::Mason make this easy), and if they're not, they get a generic > >version. This required two changes: > > > > - Apache::AuthCookie should be able to recognize whether a user is logged > > in, *even for unprotected documents*. > > > > - Since a user can access a document regardless of whether he/she is > > logged in, and since the user should be able to log in at any time, the > > login procedure should be trigerrable by some means other than simply > > accessing a protected document. > > > >The key change is that there's now a URL (I've called it LOGIN) and > >corresponding method (Apache::AuthCookie->login()) that handles a > >user's initial login. After login, the user is redirected to the page > >they requested. This means that the authen() method doesn't have to > >implement such complicated logic anymore - if the user sent a cookie, > >check its validity. If not, redirect to the login form. That meant I > >could rip out a lot of the code from the authen() method. > > > >There's also a new recognize_user() method which checks to see whether > >a valid authentication cookie has been sent, and if so, sets > >$r->connection->user. > > > > > >As a bonus side-effect, AuthCookie can now authenticate even when the > >requested page URL has a non-empty query string (this has been a > >limitation of AuthCookie). This is because the redirection URL is now > >simply sent in the login form as a hidden field, so it can contain > >whatever query information it wants. > > > > > >It's important to note that these changes are not fully backward-compatible > >with previous versions. Some modifications will be required to adopters' > >..htaccess files and login forms. Here's what mine look like. The login form > >can be on any page, allowing the user to log in at any time: > > > > > > > > > > > > username: > > password: > > > > > > > >My .htaccess file (in a /listeners/ directory) is as follows. MMAuth is a > >subclass of Apache::AuthCookie, implementing the authen_cred() and > >authen_ses_key() methods. > > > > > > AuthType MMAuth > > AuthName Listener > > PerlSetVar ListenerPath /listeners/ > > PerlSetVar ListenerLoginScript /listeners/login.pl > > PerlSetVar MMSessionExpiration 480 > > PerlFixupHandler MMAuth->recognize_user > > > > > > SetHandler perl-script > > PerlHandler MMAuth->login > > > > > > > > PerlAuthenHandler MMAuth->authen > > PerlAuthzHandler MMAuth->authz > > require valid-user > > > > > >Standard subclasses of Apache::AuthCookie should not require any > >changes unless they're wacky (i.e. change more than just the > >authen_cred() and authen_ses_key() methods). > > > > > > > > ------ > > Ken Williams Last Bastion of Euclidity > > [EMAIL PROTECTED]The Math Forum > > - - > Ken Williams Tech Mirror Music > [EMAIL PROTECTED] http://www.mirrormusic.com > > > -- Salon Internet http://www.salon.com/ HTTP mechanic, Perl diver, Mebwaster, Some of the above Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326
Re: Patch for Apache::AuthCookie
Hi folks, I haven't gotten any response about this. My email to Eric Bartley (the author of Apache::AuthCookie) bounced - does anyone know how to contact him, or whether there's a new maintainer? If we can't find him, I suppose we should either make a new module for this (Apache::CookieAuth?) or find a new maintainer for AuthCookie. [EMAIL PROTECTED] (Ken Williams) wrote: >Hi mod_perl-ers, > >I've been working with the Apache::AuthCookie module, and have made a >couple of modifications that make it more flexible. As an added >benefit, the code is now shorter and simpler. =) I hereby submit the >code for discussion and possible adoption by Eric. Patch attached. > >The motivation for this was that I wanted users to be able to access >certain documents whether they're logged in or not. If they're logged >in, they should get a customized version of the document (packages like >HTML::Mason make this easy), and if they're not, they get a generic >version. This required two changes: > > - Apache::AuthCookie should be able to recognize whether a user is logged > in, *even for unprotected documents*. > > - Since a user can access a document regardless of whether he/she is > logged in, and since the user should be able to log in at any time, the > login procedure should be trigerrable by some means other than simply > accessing a protected document. > >The key change is that there's now a URL (I've called it LOGIN) and >corresponding method (Apache::AuthCookie->login()) that handles a >user's initial login. After login, the user is redirected to the page >they requested. This means that the authen() method doesn't have to >implement such complicated logic anymore - if the user sent a cookie, >check its validity. If not, redirect to the login form. That meant I >could rip out a lot of the code from the authen() method. > >There's also a new recognize_user() method which checks to see whether >a valid authentication cookie has been sent, and if so, sets >$r->connection->user. > > >As a bonus side-effect, AuthCookie can now authenticate even when the >requested page URL has a non-empty query string (this has been a >limitation of AuthCookie). This is because the redirection URL is now >simply sent in the login form as a hidden field, so it can contain >whatever query information it wants. > > >It's important to note that these changes are not fully backward-compatible >with previous versions. Some modifications will be required to adopters' >..htaccess files and login forms. Here's what mine look like. The login form >can be on any page, allowing the user to log in at any time: > > > > > > username: > password: > > > >My .htaccess file (in a /listeners/ directory) is as follows. MMAuth is a >subclass of Apache::AuthCookie, implementing the authen_cred() and >authen_ses_key() methods. > > > AuthType MMAuth > AuthName Listener > PerlSetVar ListenerPath /listeners/ > PerlSetVar ListenerLoginScript /listeners/login.pl > PerlSetVar MMSessionExpiration 480 > PerlFixupHandler MMAuth->recognize_user > > > SetHandler perl-script > PerlHandler MMAuth->login > > > > PerlAuthenHandler MMAuth->authen > PerlAuthzHandler MMAuth->authz > require valid-user > > >Standard subclasses of Apache::AuthCookie should not require any >changes unless they're wacky (i.e. change more than just the >authen_cred() and authen_ses_key() methods). > > > > ------ > Ken Williams Last Bastion of Euclidity > [EMAIL PROTECTED]The Math Forum - - Ken Williams Tech Mirror Music [EMAIL PROTECTED] http://www.mirrormusic.com
Re: Patch for Apache::AuthCookie
Oops - the patch I attached was missing a line. The second line in the recognize_user() routine should be: my $debug = $r->dir_config("AuthCookieDebug") || 0; or else the thing doesn't even compile. Last-minute changes, you know... =) [EMAIL PROTECTED] (Ken Williams) wrote: >Hi mod_perl-ers, > >I've been working with the Apache::AuthCookie module, and have made a >couple of modifications that make it more flexible. As an added >benefit, the code is now shorter and simpler. =) I hereby submit the >code for discussion and possible adoption by Eric. Patch attached. - - Ken Williams Tech Mirror Music [EMAIL PROTECTED] http://www.mirrormusic.com