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: Location / AuthType TAS::Cookie AuthName TAS PerlFixupHandler TAS::Cookie-recognize_user /Location 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
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
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
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
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!!
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
AuthCookie with a modified version of Authticket unable to delete the cookie (logout)
Hi All,
I am having problems using Authcookie 3.0 and a modified version of
AuthTicket 0.31
The problem is that I am not able to log off (delete the cookie). This is
frustrating :-(
I have everything else working correctly. Here is what I have done:
In my http.conf file I have defined the appropriate directives:
PerlModule Apache::AuthCookie
PerlModule Apache::PLMSolutions
PerlSetVar Apache::PLMSolutions /
PerlSetVar PLMSolutionsLoginScript /PLMSolutionsloginform
PerlSetVar PLMSolutionsLogoutScript /PLMSolutionslogout
PerlSetVar PLMSolutionsTicketLoginHandler /PLMSolutionslogin
PerlSetVar PLMSolutionsLoginScript /PLMSolutionsloginform
PerlSetVar AuthCookieDebug 3
Location /cgi-bin/uganswer/bin/
AuthType Apache::PLMSolutions
AuthName PLMSolutions
PerlAuthenHandler Apache::PLMSolutions-authenticate
PerlAuthzHandler Apache::PLMSolutions-authorize
require valid-user
/Location
Location /PLMSolutionsloginform
AuthType Apache::PLMSolutions
AuthName PLMSolutions
SetHandler perl-script
Perlhandler Apache::PLMSolutions-login_screen
/Location
Location /PLMSolutionslogin
AuthType Apache::PLMSolutions
AuthName PLMSolutions
SetHandler perl-script
PerlHandler Apache::PLMSolutions-login
/Location
Location /PLMSolutionslogout
AuthType Apache::PLMSolutions
AuthName PLMSolutions
SetHandler perl-script
PerlHandler Apache::PLMSolutions-logout
/Location
Ok, I have created a PLMSolutions.pm module located in
perl5.8.0/lib/site_perl/5.8.0/Apache
directory with this logout function defined as follows:
sub logout{
my ($class, $r) = @_;
my $this = $class-new($r);
$this-SUPER::logout($r);
$r-err_headers_out-add('Location' = $this-{TicketLogoutURI});
return REDIRECT;
}
On my HTML form I have defined the logout as this:
FONT size=+1 color=#3C3CFF
INPUT type=submit name=function value=logout
action=/PLMSolutionslogout
/FONT
/FORM
In the apache error_log file I have this listed:
Tue Mar 4 06:29:51 2003] [error] uri /cgi-bin/uganswer/bin/new_uga.cgi
[Tue Mar 4 06:29:52 2003] PerlHandler subroutine
`Apache::PLMSolutions-login_screen': returning [/PLMSolutionslogin] for
TicketL
oginHandler at /app/perl5.8.0/lib/site_perl/5.8.0/Apache/PLMSolutions.pm
line 140.
[Tue Mar 4 06:29:52 2003] [error] REASON FOR AUTH NEEDED: no_cookie
[Tue Mar 4 06:29:52 2003] [error] AUTHTICKET REASON:
[Tue Mar 4 06:30:01 2003] [error] credential_0 hillr
[Tue Mar 4 06:30:01 2003] [error] credential_1 br3828
[Tue Mar 4 06:30:01 2003] [error] ses_key hillr:Ron Hill
[Tue Mar 4 06:30:01 2003] [error] auth_type Apache::PLMSolutions
[Tue Mar 4 06:30:01 2003] [error] auth_name PLMSolutions
[Tue Mar 4 06:30:01 2003] [error] ses_key_cookie hillr:Ron Hill
[Tue Mar 4 06:30:01 2003] [error] uri /cgi-bin/uganswer/bin/new_uga.cgi
[Tue Mar 4 06:30:01 2003] [error] user authenticated as hillr
[Tue Mar 4 06:30:01 2003] [error] requirement := valid-user,
[Tue Mar 4 06:30:07 2003] [error] auth_type Apache::PLMSolutions
[Tue Mar 4 06:30:07 2003] [error] auth_name PLMSolutions
[Tue Mar 4 06:30:07 2003] [error] ses_key_cookie hillr:Ron Hill
[Tue Mar 4 06:30:07 2003] [error] uri /cgi-bin/uganswer/bin/new_uga.cgi
[Tue Mar 4 06:30:07 2003] [error] user authenticated as hillr
[Tue Mar 4 06:30:07 2003] [error] requirement := valid-user,
Wherever I click the logout button on my form the script just returnes me
to the currect screen I was expecting to go to www-gtac (since that is what
I have defined in the TicketLogoutURI ).
Can someone point out what I am doing wrong? (and how to fix it).
One other question, how can I change the name of the cookie?
(currently is is Apache::PLMSolutions_PLMSolutions)
Thanks for any help you can provide.
Ron Hill
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 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-:+-$-gprint$_.$/}
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-:+-$-gprint$_.$/}
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-:+-$-gprint$_.$/}
AuthCookie Frames
I'm having a slight problem using AuthCookie in our app because our app
(unfortunately) is a frames-based interface. To summarize the problem and
efforts I've made to date, my goal is to be able to display a message on the
login page telling them why they are seeing the login page. Options are:
'Login Incorrect', 'Previous Session Timed Out', 'Session Deactivated Due To
Login From Another Location', etc...
My first attempt was to try to just set values in the subprocess_env, and
since AuthCookie works by removing a user's cookie and then doing redirects
to the login page if a user is not validly logged in, I could always just
look at $r-prev-subprocess_env('login_error_msg') for the cause. However,
since I am using frames, this doesn't work in all cases.
If for example a user is currently at a part of the site that has three
frames, and then walks to his co-workers office and uses that computer to
log in, we have invalidated his old session back at his desk. If he goes
back to his own desk and tries to navigate in the app, we want to redirect
to a login page with the message 'Session Deactivated Due To Login From
Another Location'. However, what happens is that he goes to click on
something, javascript gets called that changes the contents of all three
frames, so all three frames try to load new content. This means 3 new
requests, and 3 passes through AuthCookie. Well the first pass through
works exactly like I would expect and
$r-prev-subprocess_env('login_error_msg') has the proper error message.
The problem is that the other two requests also go through AuthCookie, and
since the first one already removed the cookie, the other two just see that
the user doesn't have a cookie and also redirect to the login page. So what
the user is seeing is really the third redirect to the login page, which no
longer has any useful info in $r-prev-subprocess_env.
So my next thought was that we need some sort of global login messages
object that could be shared across children and requests and could hold
login failure messages. Since I'm already using Apache::Session, I thought
following the cookbook's recipe on how to use A::S for global data would be
good. So I set up a session with a known key (_loginmsgs) but then
realized there's no piece of info I can use to uniquely identify a
particular user/browser so that I can store a message for him. I can't use
the session key since by the time it comes to look up if there are any
messages I should be displaying on the login page, there's no longer a
session key to reference (the cookie has been removed). I then thought I
could just try the IP address but firewalls could make multiple users look
to be coming from the same IP. I never really came up with something I
thought would work and was clean. So, finally, the question is has anyone
solved this same problem, or does anyone have any ideas of what I should
try?
Thanks,
Fran
AuthCookie questions
I'm considering use of Apache::AuthCookie in my environment. Here's the problem I need to solve. I'm not certain if AuthCookie will, without modification, support my needs. 1. Authentication cookies are doled out from a centralized server that is out of my control and cannot be modified to suit my local needs (if any). 2. If the cookie is not present when a user hits my site, I redirect to the centralized server and leave breadcrumbs in the redirect for the cookie server to redirect back to me after giving out the cookie. 3. I need to parse the cookie to determine validity and populate certain environmental variables. 4. I cannot modify the cookie and should not send additional cookies. I know that AuthCookie in combination with a locally-written subclass to implement the authen_ses_key method will handle needs 1-3. I'm uncertain about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be something that AuthCookie be modified to handle? Thanks, Christian - Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group
Re: AuthCookie questions
Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
protecting and entire site with AuthCookie and its derivatives?
Is it possible to protect an entire site, from DocumentRoot, using AuthCookie? I have tried to configured it today, using my subclass of AuthCookieDBI: - If I have all of the protected files in Location blocks under Document root, all is fine. - If I try to protect Location /, then it appears that /login.pl is protected by itself and enters a endless loop. The suggested settings from the AuthCookie docs are : PerlSetVar WhatEverLoginScript /login.pl # This is the action of the login.pl script above. Files LOGIN AuthType Sample::AuthCookieHandler AuthName WhatEver SetHandler perl-script PerlHandler Sample::AuthCookieHandler-login /Files Both locations (/login.pl and LOGIN seem to be under DocumentRoot by default, so I can't see how to protect DocumentRoot with this authentication scheme. I am sure I am missing something obvious thoughcan someone please tell me what it is? :) Thanks in advance, GV
RE: AuthCookie questions
Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. 1. Foreign server, foreign.foo.com, presents a form to a user requesting userid/password. Foreign server accepts credentials and creates simple session cookie whose domain is foo.com containing a string of unencrypted key/value pairs. 2. User comes to my local server, local.foo.com, and sends along his cookie for domain foo.com. I need to parse out one of the key/value pairs and populate an environment variable (aside from REMOTE_USER) with the pair's data. If the user comes without the cookie or without appropriate data in the cookie, I need to redirect him to foreign. I am also asked to not create any other cookies. All the data I need is in the one cookie that comes from foreign. So, my needs boil down to: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. Thanks, Christian - Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group -Original Message- From: Michael Schout [mailto:mschout;gkg.net] Sent: Tuesday, October 22, 2002 2:00 PM To: Christian Gilmore Cc: Modperl Mailing List (E-mail) Subject: Re: AuthCookie questions Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
Re: AuthCookie questions
Christian Gilmore wrote: Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. [...] On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. It sounds like you are already aware that it lacks security. The important thing to remember about cookies is that unless you use some kind of cryptographic signature to verify them you have absolutely no idea if the cookie came from your site or not. People can very easilly put whatever they want in a cookie to send to your site usingone of the thousands of HTTP testing programs and libraries, and if you use that cookie as a key to a data structure they may be able to gain access to other people's data. Even if you use a crypto signature they can still sniff someone else's legit cookie off the wire, but at least you can prevent them from tampering with the contents of the cookie. Never trust the client. - Perrin
Re: protecting and entire site with AuthCookie and its derivatives?
George Valpak wrote: Is it possible to protect an entire site, from DocumentRoot, using AuthCookie? Yes. I've never done this myself personally, but people have reported success doing this. The trick is to configure apache so that your LOGIN handler is not inside the authentication realm. Since your wanting to protect the whole server, the trick is to use LocationMatch directives to specify that everything EXCEPT /LOGIN (or whatever your login handler is) gets protected. I dont have a configuration to post to you that will work because I've never done it, but its definitely possible becuase others have had success with it. Mike
Re: AuthCookie questions
Christian Gilmore wrote: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. Sounds to me like you really dont need AuthCookie at all. You could just as easily do all of this by writing a PerlAccessHandler that does the above things. I'll second Perrin's comments. You definately have security problems with this. The only way to do this securely is to cryptograpically sign the cookie and to encrypt the data on the wire using SSL. Mike
Re: AuthCookie questions
check here http://modperl.home.att.net Peter - Original Message - From: Christian Gilmore [EMAIL PROTECTED] To: 'Michael Schout' [EMAIL PROTECTED] Cc: 'Modperl Mailing List (E-mail)' [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 12:13 PM Subject: RE: AuthCookie questions Hi, Michael. Let me try again with more specifics. I'm required to mash my service into another organization's authentication scheme, ditching my own secure methods for their cross-domain unencrypted, unsigned cookie. 1. Foreign server, foreign.foo.com, presents a form to a user requesting userid/password. Foreign server accepts credentials and creates simple session cookie whose domain is foo.com containing a string of unencrypted key/value pairs. 2. User comes to my local server, local.foo.com, and sends along his cookie for domain foo.com. I need to parse out one of the key/value pairs and populate an environment variable (aside from REMOTE_USER) with the pair's data. If the user comes without the cookie or without appropriate data in the cookie, I need to redirect him to foreign. I am also asked to not create any other cookies. All the data I need is in the one cookie that comes from foreign. So, my needs boil down to: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. On a side note, if anyone finds the proposed design lacking for security or anything else, please let me know. Thanks, Christian - Christian Gilmore Technology Leader GeT WW Global Applications Development IBM Software Group -Original Message- From: Michael Schout [mailto:mschout;gkg.net] Sent: Tuesday, October 22, 2002 2:00 PM To: Christian Gilmore Cc: Modperl Mailing List (E-mail) Subject: Re: AuthCookie questions Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean The user cannot modify the cookie? If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
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.
Re: (browser bug) Internet Explorer AuthCookie and others
I am an idiot. Please ignore the previous post.
Richard :(
- Original Message -
From: Richard Clarke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 2:00 AM
Subject: (browser bug) Internet Explorer AuthCookie and others
List,
I just wanted to post to see if anyone could help me understand this
(probably internet explorer) based problem. In the past I have used my own
custom authcookie type modules. Sometimes I experience problems where
internet explorer sends back a cookie with the incorrect hash (maybe an
old
cookie) and causes the authentication to fail since the hash's don't
match.
I didn't have this problem too often though. However I am trying out
Apache::dnszone which uses AuthCookie. The same type of things happens
with
AuthCookie except here it happens nearly EVERY time I try to perform a
priviliged operation. Of course with mozilla it works perfectly every
time.
Is this another browser based bug?
The section of AuthTicker.pm which croaks the error is
my $newhash = md5_hex($secret .
md5_hex(join ':', $secret, $ip,
@ticket{qw(version time expires user)})
);
unless ($newhash eq $ticket{'hash'}) {
# ticket hash does not match (ticket tampered with?)
$r-subprocess_env(AuthTicketReason = 'tampered_hash');
return 0;
}
---
This is pretty much identical code to where my code croaks (except mine
doesnt seem as often).
So I'm guessing internet explorer screws up somehow and sends and old
cookie
or something weird. No doubt others have experience this and know what is
happening. Please explain
Yours,
Richard
[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
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: 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/
Re: Getting AuthCookie to work on W2K
On Thu, 30 May 2002, Hill, Ronald wrote: Hello All, I am trying to setup the Apache-AuthCookie module and have run into a problem. Every time I try to login it just returns my back to the login screen. I can't get past the login screen!! (I have tried with Netscape and IE). Next I wrote a perl script to check things out. (same thing!!) according to the apache log file it seems that the server is not receiving the cookie but according to the LWP debug information it is sending it out!! Does anyone have any idea what is wrong? What have I missed? I've tried a simple example of AuthCookie on Win32, and it works, so it's not a compatibility issue in principle. One thing to check - is your login form set up in the way AuthCookie expects it (see 'perldoc Apache::AuthCookie') - username and password in parameters called 'credential_0' and 'credential_1', and also a 'destination' parameter set to the location where the user should be taken if the login is successful? best regards, randy kobes
Getting AuthCookie to work on W2K
Hello All,
I am trying to setup the Apache-AuthCookie module and have run into a
problem. Every time
I try to login it just returns my back to the login screen. I can't get past
the login screen!!
(I have tried with Netscape and IE). Next I wrote a perl script to check
things out. (same thing!!)
according to the apache log file it seems that the server is not receiving
the cookie but according
to the LWP debug information it is sending it out!!
Does anyone have any idea what is wrong? What have I missed?
Thanks
Ron
login.pl script=
#!/usr/bin/perl -w
use HTTP::Request::Common;
use HTML::Form;
use LWP::UserAgent;
use LWP::Debug qw(+);
BEGIN {
local $^W = 0;
*LWP::UserAgent::redirect_ok = sub {1}
}
use HTTP::Cookies;
use strict;
my $ua= LWP::UserAgent-new;
$ua-cookie_jar(
HTTP::Cookies-new(
autosave = 1 )
);
my $request = $ua-request( POST 'http://cypci748/uganswer/index.html' );
#print $request-as_string;
my $form = HTML::Form-parse( $request-content, $request-base());
$form-value( 'credential_0', programmer );
$form-value( 'credential_1', Hero );
my $response = $ua-request( $form-click('submit') );
print $response-as_string;
=output from login.pl (lwp debug
information)=
F:\scriptslogin.pl
LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/uganswer/index.html
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 763 bytes
LWP::Protocol::collect: read 692 bytes
LWP::UserAgent::request: Simple response: OK
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/LOGIN
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 265 bytes
HTTP::Cookies::extract_cookies: Set cookie Apache::UGA::AuthCookieHandler_Wh
er = programmer:Hero
LWP::UserAgent::request: Simple response: Found
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking cypci748.local for cookies
HTTP::Cookies::add_cookie_header: Checking .local for cookies
LWP::UserAgent::send_request: POST http://cypci748/uganswer/index.html
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 763 bytes
LWP::Protocol::collect: read 692 bytes
LWP::UserAgent::request: Simple response: OK
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Date: Thu, 30 May 2002 13:51:59 GMT
Pragma: no-cache
Server: Apache/1.3.19 (Win32) AxKit/1.51 mod_perl/1.26
Content-Length: 1455
Content-Type: text/html
Expires: Thu, 30 May 2002 13:51:59 GMT
Client-Date: Thu, 30 May 2002 13:51:59 GMT
Client-Response-Num: 1
[ the login form was here]
Apache error_log
file===
[Thu May 30 06:51:59 2002] [error] auth_type Apache::UGA::AuthCookieHandler
[Thu May 30 06:51:59 2002] [error] auth_name WhatEver
[Thu May 30 06:51:59 2002] [error] ses_key_cookie
[Thu May 30 06:51:59 2002] [error] uri /uganswer/index.html
[Thu May 30 06:51:59 2002] [error] Converting POST - GET
[Thu May 30 06:51:59 2002] [error] credential_0 programmer
[Thu May 30 06:51:59 2002] [error] credential_1 Hero
[Thu May 30 06:51:59 2002] [error] ses_key programmer:Hero
[Thu May 30 06:51:59 2002] [error] auth_type Apache::UGA::AuthCookieHandler
[Thu May 30 06:51:59 2002] [error] auth_name WhatEver
[Thu May 30 06:51:59 2002] [error] ses_key_cookie
[Thu May 30 06:51:59 2002] [error] uri /uganswer/index.html
Apache http.conf file for
AuthCookie
Location /perl/
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Location
PerlModule Apache::AuthCookie
PerlModule Apache::UGA::AuthCookieHandler
PerlSetVar WhatEverPath f:/Apache/cgi-bin/
PerlSetVar WhatEverLoginScript /perl/login.pl
PerlSetVar AuthCookieDebug 3
Location /uganswer/
AuthType Apache::UGA::AuthCookieHandler
AuthName WhatEver
PerlAuthenHandler Apache::UGA::AuthCookieHandler-authenticate
PerlAuthzHandler Apache::UGA::AuthCookieHandler-authorize
Require user programmer
/Location
Location /LOGIN
AuthType Apache::UGA::AuthCookieHandler
AuthName WhatEver
SetHandler perl-script
PerlHandler Apache::UGA::AuthCookieHandler-login
/Location
Re: AuthCookie help
Jian Zhen wrote: Hi all, I have been scratching my head for a day now trying to figure out how to make AuthCookie work. I note that you have PerlSetVar WhatEverSecure 1 in your config. If that is the case, make sure you are accessing the from using HTTPS, not HTTP. This has been a common cause of this behaviour. With WhatEverSecure 1, the cookie will only be returned to the server on an SSL connection, but not a plain HTTP connection. I probably should document this better in the POD docs... Mike
Re: AuthCookie help
Mike, Thx for your response. I am actually accessing it through https and still have the same problem. I tried putting things in either .htaccess or httpd.conf, but that doesn't seem to help either. Any other idea what might be wrong here? thx again for ur help // Jian Michael Schout ([EMAIL PROTECTED]) [020515 09:11]: Jian Zhen wrote: Hi all, I have been scratching my head for a day now trying to figure out how to make AuthCookie work. I note that you have PerlSetVar WhatEverSecure 1 in your config. If that is the case, make sure you are accessing the from using HTTPS, not HTTP. This has been a common cause of this behaviour. With WhatEverSecure 1, the cookie will only be returned to the server on an SSL connection, but not a plain HTTP connection. I probably should document this better in the POD docs... Mike
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
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: 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]
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: 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.
Re: framesets/AuthCookie question
On Mon, 22 Apr 2002, Fran Fabrizio wrote: It seems that even if AuthCookie returns a FORBIDDEN with a custom_error page set, the $r-notes() don't propagate. Does apache consider the display of the custom_response page to be a completely new request? Its a subrequest, so the notes shold be in $r-prev-notes(). Mike
Re: framesets/AuthCookie question
Followup from last week:
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom_response error page.
[snip]
...I then thought it'd be neat to include on the login page handler output
a message to tell them how they got there (Your session has expired,
Your account has logged on from another location, Invalid
username/password combination, whatever...).
At first I thought I could accomplish this by simply doing
$r-notes('LOGINFAILMSG' = 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
New observations
It seems that even if AuthCookie returns a FORBIDDEN with a custom_error
page set, the $r-notes() don't propagate. Does apache consider the
display of the custom_response page to be a completely new request?
-Fran
RE: framesets/AuthCookie question
I'm just a budding modperlie - is notes info maintained
across a server redirect?
$r-internal_redirect('/login?message=dont+go+there');
Jeff
-Original Message-
From: Michael Schout [mailto:[EMAIL PROTECTED]]
Sent: 19 April 2002 17:44
To: Peter Bi
Cc: Fran Fabrizio; [EMAIL PROTECTED]
Subject: Re: framesets/AuthCookie question
On Wed, 17 Apr 2002, Peter Bi wrote:
Fran:
You may need to 1) add a few lines of code in AuthCookie to make your
error
code aware to other methods, and 2) have a dynamic login page that
can
interpret the code. Alternatively, you may try AccessCookie I posted.
:-)
The CVS version of AuthCookie has a custom_errors() hook in it that does
this
sort of thing.
However, I dont think it will work for his problem because his
javascript code
seems to launch a NEW REQUEST, thus loosing anything that was stored
away in
$r-subprocess_env(). So the only viable option is to pass the error
codes in
they url (as part of the query string) I think.
Mike
Re: framesets/AuthCookie question
On Wed, 17 Apr 2002, Peter Bi wrote: Fran: You may need to 1) add a few lines of code in AuthCookie to make your error code aware to other methods, and 2) have a dynamic login page that can interpret the code. Alternatively, you may try AccessCookie I posted. :-) The CVS version of AuthCookie has a custom_errors() hook in it that does this sort of thing. However, I dont think it will work for his problem because his javascript code seems to launch a NEW REQUEST, thus loosing anything that was stored away in $r-subprocess_env(). So the only viable option is to pass the error codes in they url (as part of the query string) I think. Mike
framesets/AuthCookie question
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom error page.
My app has a frameset (navigation on the left, and two data frames on
the right). I know the evils of framesets, but in our case, it's the
best way to present our particular data.
What ends up happening is that if the session expires, AuthCookie
displays the login page inside whatever frameset you were clicking in,
while the other two remain on whatever they were on previously.
I made a quick solution...I told AuthCookie that my login page was
login.html. login.html had javascript which called /real/login (a
mod_perl handler) and targeted it to the top frame. All is well and now
the entire browser window gets cleared and replaced with the login page.
However...I then thought it'd be neat to include on the /real/login page
a message to tell them how they got there (Your session has expired,
Your account has logged on from another location, Invalid
username/password combination, whatever...).
At first I thought I could accomplish this by simply doing
$r-notes('LOGINFAILMSG' = 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
However, it's failing of course because I added the extra redirection of
the login.html w/ the javascript, which makes a round trip to the client
and back, so it looks like a brand new request to mod_perl, thus, no
notes() any more. Is there a solution to breaking out of the frameset
AND propagating the reason for the logout to the /real/login page?
I'd appreciate and and all ideas. Thanks!
-Fran
Re: framesets/AuthCookie question
Fran:
You may need to 1) add a few lines of code in AuthCookie to make your error
code aware to other methods, and 2) have a dynamic login page that can
interpret the code. Alternatively, you may try AccessCookie I posted. :-)
In AccessCookie, you simply return $error from authenticate(), let login
page() catch the code and display corresponding instruction. I haven't
tested it in a frame set, but it should appear a login page with custom
instructions in the last window the user visited before the expiration time.
The user re-types login/password, then is redirected to the page he tried
before.
Peter Bi
- Original Message -
From: Fran Fabrizio [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 17, 2002 3:01 PM
Subject: framesets/AuthCookie question
I'm using AuthCookie and as some of you know, if it determines your
session to be invalid it redirects to a login page instead by way of a
FORBIDDEN response coupled with a custom error page.
My app has a frameset (navigation on the left, and two data frames on
the right). I know the evils of framesets, but in our case, it's the
best way to present our particular data.
What ends up happening is that if the session expires, AuthCookie
displays the login page inside whatever frameset you were clicking in,
while the other two remain on whatever they were on previously.
I made a quick solution...I told AuthCookie that my login page was
login.html. login.html had javascript which called /real/login (a
mod_perl handler) and targeted it to the top frame. All is well and now
the entire browser window gets cleared and replaced with the login page.
However...I then thought it'd be neat to include on the /real/login page
a message to tell them how they got there (Your session has expired,
Your account has logged on from another location, Invalid
username/password combination, whatever...).
At first I thought I could accomplish this by simply doing
$r-notes('LOGINFAILMSG' = 'Your session has expired') if AuthCookie
detected it to be thus, and then in my handler I could retrieve it and
display it.
However, it's failing of course because I added the extra redirection of
the login.html w/ the javascript, which makes a round trip to the client
and back, so it looks like a brand new request to mod_perl, thus, no
notes() any more. Is there a solution to breaking out of the frameset
AND propagating the reason for the logout to the /real/login page?
I'd appreciate and and all ideas. Thanks!
-Fran
Re: AuthCookie login ?
On Fri, 5 Apr 2002, Geoffrey Young wrote: Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. can't you do this in authen_cred()? IIRC authen_cred is only called when no cookie is found, which means you have a first time visit (or an unsuccessful Yes, do it in authen_cred() after you have checked the credentials, but before returning the username. authen_cred() is only called when you submit the login form. Regards, Michael Schout (AuthCookie maintainer).
AuthCookie login ?
Is there a hook in AuthCookie to allow me to run some code only right after successful login? The model doesn't seem to allow for this. The way it seems to work is you attempt to log in, if it doesn't find a valid cookie, it displays the login form again. You submit that and it sets the cookie without authenticating the login, then issues a redirect to the page the user was originally trying to go to. When the browser comes back via the redirect, the cookie is already present, and only then does AuthCookie attempt to authenticate the cookie. Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. It would seem wasteful to check for the presence of the Apache::Session object every trip to the server just to determine if this is the first request or not. Is there a hook or a flag with that same functionality? Thanks, Fran
Re: AuthCookie login ?
Since the authentication happens on every trip into the server, and I don't want to run my code (to set up an Apache::Session for the user's session data) until I'm sure I have a valid user on my hands, I can't see a way to do the session setup only the first time after a sucessful login. can't you do this in authen_cred()? IIRC authen_cred is only called when no cookie is found, which means you have a first time visit (or an unsuccessful attempt). you have control here to execute code only when a valid user is found, since it's up to you to determine if the user is valid. authen_ses_key() then checks whether the cookie itself (containing the session key) is valid. at least this is how I remember it working - it's been a while since I've worked with AuthCookie. --Geoff
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
Location /agenda/ 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/. Location /LOGIN/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location 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: Apache::AuthCookie not set cookie really
Location /agenda/ 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/. Location /LOGIN/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location 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) Location /agenda/ SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaPath /agenda PerlSetVar AgendaTemplate default.inc PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ . /Location Location /LOGIN/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location 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 Location /agenda SetHandler perl-script PerlHandler Apache::Agenda PerlSetVar AgendaSessionDir /tmp PerlSetVar AgendaLoginScript /agenda/login/ . /Location Location /agendalogin/ AuthType Apache::AuthCookieAgenda AuthName Agenda SetHandler perl-script PerlHandler Apache::AuthCookieAgenda-login /Location 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
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]
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
IfDefine power
Perl
use lib qw(/usr/web/inc /usr/web/dev.webzavod.ru/modules);
use Apache::Agenda;
use Apache::AuthCookieAgenda;
/Perl
PerlInitHandler Apache::Reload
PerlSetVar AuthCookieDebug 10
Location /agenda/
SetHandler perl-script
PerlHandler Apache::Agenda
PerlSetVar AgendaPath /agenda
PerlSetVar AgendaTemplate default.inc
PerlSetVar AgendaSessionDir /tmp
PerlSetVar AgendaLoginScript /agenda/login/
AuthType Apache::AuthCookieAgenda
AuthName Agenda
PerlAuthenHandler Apache::AuthCookieAgenda-authenticate
PerlAuthzHandler Apache::AuthCookieAgenda-authorize
require valid-user
/Location
Location /LOGIN/
AuthType Apache::AuthCookieAgenda
AuthName Agenda
SetHandler perl-script
PerlHandler Apache::AuthCookieAgenda-login
/Location
/IfDefine
when I'm trying to access /agenda/ files I get login page, but after
submit a form, I return to login page again.
In logs
[Mon Jan 28 12:38:35 2002] [error] credential_0 asdasd
[Mon Jan 28 12:38:35 2002] [error] credential_1 asdasd
[Mon Jan 28 12:38:35 2002] [error] ses_key asdasd:asdasd
OUT Headers goes here
$VAR1 = 'Pragma';
$VAR2 = 'no-cache';
$VAR3 = 'Cache-control';
$VAR4 = 'no-cache';
$VAR5 = 'Location';
$VAR6 = '/agenda/tasks/';
Error OUT Headers goes here
$VAR1 = 'Set-Cookie';
$VAR2 = 'Apache::AuthCookieAgenda_Agenda=asdasd:asdasd';
$VAR3 = 'Pragma';
$VAR4 = 'no-cache';
Redirecting...
and next phase
[Mon Jan 28 12:38:35 2002] [error] auth_type Apache::AuthCookieAgenda
[Mon Jan 28 12:38:35 2002] [error] auth_name Agenda
[Mon Jan 28 12:38:35 2002] [error] ses_key_cookie
Cookie field is empty here - I don't know why...
Cookie is set via error headers, I know that it is correct for
REDIRECT responses...
ses_key_cookie is empty, therefore authen_ses_key not even requested,
redirecting to login form again.
[Mon Jan 28 12:38:35 2002] [error] uri /agenda/tasks/
[Mon Jan 28 12:38:35 2002] [error] auth_type Apache::AuthCookieAgenda
[Mon Jan 28 12:38:35 2002] [warn] Header Dump:
GET /agenda/tasks/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/ms
word, */*
Accept-Encoding: gzip, deflate
Accept-Language: ru
Cache-Control: no-cache
Cookie: SESSION_ID=1000_56535df97f6ed52c
I used Apache::Session::Counted, and know that this two modules may
conflict, but when all Apache::Session::Counted staff is commented
result is the same...
Host: warzavod:81
Referer: http://warzavod/agenda/tasks/
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461)
X-Real-IP: 195.209.67.7
I dont know why cookie is not set.
Is there anywhere comparison table for
Apache::AuthCookie - Apache::AuthTicket
and table for
Apache::Session modules - I use Apache::Session::Counted as the single
not-database solution wich I found for maintaining state with cleanup
feature. Or is there anywhere cleanup example for Apache::Session - I
didn't find... Apache::Session::Lock::File-clean cleans up only lock
files...
Apache::ASP - has a good session state algorithm with cleanup...
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]
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
IfDefine power
Perl
use lib qw(/usr/web/inc /usr/web/dev.webzavod.ru/modules);
use Apache::Agenda;
use Apache::AuthCookieAgenda;
/Perl
PerlInitHandler Apache::Reload
PerlSetVar AuthCookieDebug 10
Location /agenda/
SetHandler perl-script
PerlHandler Apache::Agenda
PerlSetVar AgendaPath /agenda
PerlSetVar AgendaTemplate default.inc
PerlSetVar AgendaSessionDir /tmp
PerlSetVar AgendaLoginScript /agenda/login/
AuthType Apache::AuthCookieAgenda
AuthName Agenda
PerlAuthenHandler Apache::AuthCookieAgenda-authenticate
PerlAuthzHandler Apache::AuthCookieAgenda-authorize
require valid-user
/Location
Location /LOGIN/
AuthType Apache::AuthCookieAgenda
AuthName Agenda
SetHandler perl-script
PerlHandler Apache::AuthCookieAgenda-login
/Location
/IfDefine
when I'm trying to access /agenda/ files I get login page, but after
submit a form, I return to login page again.
In logs
[Mon Jan 28 12:38:35 2002] [error] credential_0 asdasd
[Mon Jan 28 12:38:35 2002] [error] credential_1 asdasd
[Mon Jan 28 12:38:35 2002] [error] ses_key asdasd:asdasd
OUT Headers goes here
$VAR1 = 'Pragma';
$VAR2 = 'no-cache';
$VAR3 = 'Cache-control';
$VAR4 = 'no-cache';
$VAR5 = 'Location';
$VAR6 = '/agenda/tasks/';
Error OUT Headers goes here
$VAR1 = 'Set-Cookie';
$VAR2 = 'Apache::AuthCookieAgenda_Agenda=asdasd:asdasd';
$VAR3 = 'Pragma';
$VAR4 = 'no-cache';
Redirecting...
and next phase
[Mon Jan 28 12:38:35 2002] [error] auth_type
Apache::AuthCookieAgenda
[Mon Jan 28 12:38:35 2002] [error] auth_name Agenda
[Mon Jan 28 12:38:35 2002] [error] ses_key_cookie
Cookie field is empty here - I don't know why...
Cookie is set via error headers, I know that it is correct for
REDIRECT responses...
ses_key_cookie is empty, therefore authen_ses_key not even
requested,
redirecting to login form again.
[Mon Jan 28 12:38:35 2002] [error] uri /agenda/tasks/
[Mon Jan 28 12:38:35 2002] [error] auth_type
Apache::AuthCookieAgenda
[Mon Jan 28 12:38:35 2002] [warn] Header Dump:
GET /agenda/tasks/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/ms
word, */*
Accept-Encoding: gzip, deflate
Accept-Language: ru
Cache-Control: no-cache
Cookie: SESSION_ID=1000_56535df97f6ed52c
I used Apache::Session::Counted, and know that this two modules may
conflict, but when all Apache::Session::Counted staff is commented
result is the same...
Host: warzavod:81
Referer: http://warzavod/agenda/tasks/
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461)
X-Real-IP: 195.209.67.7
I dont know why cookie is not set.
Is there anywhere comparison table for
Apache::AuthCookie - Apache::AuthTicket
and table for
Apache::Session modules - I use Apache::Session::Counted as the
single
not-database solution wich I found for maintaining state with
cleanup
feature. Or is there anywhere cleanup example for Apache::Session -
I
didn't find... Apache::Session::Lock::File-clean cleans up only
lock
files...
Apache::ASP - has a good session state algorithm with cleanup...
Ok.
I readed the previous discuss with
http://marc.theaimsgroup.com/?t=10110064594r=1w=2
And ask the question in more general form.
Our team writing project management open source system Agenda.
There is a couple groupware application written on php, I installed
every of them.
All of them cannot be used for
1. Company with greater than 1 department
2. With one or more
Re: AuthSession Manager [was] Apache::AuthCookie not set cookie really
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
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: HTML HEADTITLEAn Error Occurred/TITLE/HEAD BODY H1An Error Occurred/h1 403 Forbidden /BODY /HTML 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 /FilesMatch # login.pl Files LOGIN AuthType Apache::AuthCookieDBI AuthName Portal SetHandler perl-script PerlHandler Apache::AuthCookieDBI-login /Files # website. Directory /home/httpd/html/secured PerlSetVar PortalDomain .mydomain.com PerlSetVar PortalLoginScript /login.pl AuthType Apache::AuthCookieDBI AuthName Portal PerlAuthenHandler Apache::AuthCookieDBI-authenticate PerlAuthzHandler Apache::AuthCookieDBI-authorize require valid-user /Directory 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 Directory /opt/www/tgweb/protected/ AuthType Apache::AuthCookieDBI AuthName PrisInformasjon PerlAuthenHandler Apache::AuthCookieDBI-authenticate PerlAuthzHandler Apache::AuthCookieDBI-authorize require valid-user /Directory Files LOGIN AuthType Apache::AuthCookieDBI AuthName PrisInformasjon SetHandler perl-script PerlHandler Apache::AuthCookieDBI-login /Files -- Ø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. **
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 Location /tgweb/protected 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 Directory /opt/www/tgweb/protected/ AuthType Apache::AuthCookieDBI AuthName PrisInformasjon PerlAuthenHandler Apache::AuthCookieDBI-authenticate PerlAuthzHandler Apache::AuthCookieDBI-authorize require valid-user /Directory Files LOGIN AuthType Apache::AuthCookieDBI AuthName PrisInformasjon SetHandler perl-script PerlHandler Apache::AuthCookieDBI-login /Files [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. **
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.
Location /cdrloginform
SetHandler perl-script
PerlHandler Cdr::AuthCookie-login_form
/Location
# handle posted data from the login form.
location /cdrlogin
SetHandler perl-script
AuthTypeCdr::AuthCookie
AuthNameCDR
PerlHandler Cdr::AuthCookie-login
/Location
Location /foo
SetHandler perl-script
AuthTypeCdr::AuthCookie
AuthNameCDR
PerlAuthenHandler Cdr::AuthCookie-authenticate
PerlAuthzHandlerCdr::AuthCookie-authorize
PerlHandler Cdr::Hello
require valid-user
/Location
Location /foo/bar
SetHandler perl-script
AuthTypeCdr::AuthCookie
AuthNameCDR
PerlAuthenHandler Cdr::AuthCookie-authenticate
PerlAuthzHandlerCdr::AuthCookie-authorize
PerlHandler Cdr::Hello
require valid-user
/Location
###
# 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';
html
head
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2 Final//EN
base href=$ENV{BASEURL}
/head
body
form method=get action=/cdrlogin
!-- Login form for an Cdr::AuthCookie --
input type=hidden name=destination value=DEST
table
tr
th align=center colspan=2 Please Enter Your Username and Password to
log in:
tr
th align=right Username:
td align=left input type=text name=credential_0 size=12
maxlenth=12
tr
th align=right Password:
td align=left input type=password name=credential_1 size=12
maxlenth=12
tr
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
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 = HERE;
html
head
...
$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
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
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:
PFailure reason: '$reason'. Please enter your login and password to
authenticate./P
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
Apache::AuthCookie login faliure reason
Hi All, Iam 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.
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
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
authcookie segmentation faults
I had users complaining of intermittent document contains no data errors when logging in (using AuthCookie). I wrote a script to repeatedly POST to the AuthCookie LOGIN method. I am finding that after 15,000 POSTs or so, I start getting a lot of segfaults (child pid 12494 exit signal Segmentation fault (11)). It then quiets down for another 15,000 requests or so, and then segfaults some more. The mod_perl guide mentioned some problems with php, so I got rid of all the php modules. I also gather that my PerlFreshRestart setting won't matter since mod_perl is a DSO (Apache/1.3.14 mod_perl/1.24). Any tips how I can track this down?
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
-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
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
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: FW: AuthCookie Woes!
Chris Lavin [EMAIL PROTECTED] writes: I have used a sniffer and no cookie is being sent! Man this is frustrating! Are you positive the cookie domain is being set properly? -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy
Re: FW: AuthCookie Woes!
Further...no one needs to know or care about PerlMod around hereI posted a question two weeks ago about Apache::AuthDBI...and no one responded. So looks like you are on your own.. On Mon, 3 Sep 2001, Chris Lavin wrote: I have used a sniffer and no cookie is being sent! Man this is frustrating! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dzuy Nguyen Sent: Monday, September 03, 2001 9:00 PM To: [EMAIL PROTECTED] Subject: Re: AuthCookie Woes! Chris Lavin wrote: It does NOT seem to be being presented to my browser. I am utterly confused by this. I have really debugged the code and it thinks that it is instructing apache to send the cookie, but my browser never receives it. Thanx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dzuy Nguyen Sent: Monday, September 03, 2001 11:56 AM To: [EMAIL PROTECTED] Subject: Re: AuthCookie Woes! Chris Lavin wrote: I need help with Apache::Authcookie It does not seem to be sending the cookie to the Browser. For those of you familiar with AuthCookie PLEASE Help. I have heard of oddities with IE so I tried Netscape and no differnce. AuthXCookie uses error_header_out to send cookie..ThanxChris I'm pretty sure AuhthCookie sends the cookie to the browser. Whether the browser accepts it or presents it to the server is another matter. You can check the browser's cookie file to see if your cookie is in there (if your cookie has an expiration date). Make sure you set the cookie domain correctly. Normally the cookie is instructed to present the cookie to the server whose domain is as specified in the cookie. You can look into the HTTP header and see if there is a Set-Cookie: line there. To see whether the browser is sent a cookie, I'd suggest you tell the browser to warn you before accepting the cookie or better yet, get a http sniffer or write an http client and see it for yourself. -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -
FW: FW: AuthCookie Woes!
Im sorry I thought that everyone would be familiar with Appach::AuthCookie and I am usin g Apache Auth::Ticket. Thanx -Original Message- From: Peter J. Schoenster [mailto:[EMAIL PROTECTED]] Sent: Monday, September 03, 2001 11:01 PM To: [EMAIL PROTECTED] Subject: Re: FW: AuthCookie Woes! On 3 Sep 2001, at 22:36, Chris Lavin wrote: I have used a sniffer and no cookie is being sent! Man this is frustrating! I'm sure we've all been there. I haven't seen any code. Why not show how you are doing it, otherwise, I don't see how anyone could help. Peter Despite considerable evidence that it doesn't work, many projects seem to rely on telepathy as the mechanism for communicating requirements from users to developers. --Karl E. Wiegers
Re: FW: FW: AuthCookie Woes!
At 07:59 AM 9/4/2001 -0400, Chris Lavin wrote: Im sorry I thought that everyone would be familiar with Appach::AuthCookie Perhaps if you posted a tiny httpd.conf and the url of where it's running. And I'd tend to use telnet for debugging and write log messages in Apache::AuthCookie where its setting the header, and so on. Bill Moseley mailto:[EMAIL PROTECTED]
mailing list responses (was Re: FW: AuthCookie Woes!)
Further...no one needs to know or care about PerlMod around hereI posted a question two weeks ago about Apache::AuthDBI...and no one responded. So looks like you are on your own.. Not true; people do know and care about Apache:: modules around here. There are lots of reasons why you might not have received a timely response to a particular question. You may be asking about a module that no one on the list uses. You may be asking at a bad time when the people who know this module don't have time to help you. You may not have posted enough information. You may have sent your message in HTML or as an attachment (which annoys many people on this and other lists). You can ask your question again if you like, or you can check the documentation of the module in question to see if there's any more specific instructions for getting help. There's also a wealth of information in the list archives which you can search through. - Perrin
AuthCookie Woes!
I need help with Apache::Authcookie It does not seem to be sending the cookie to the Browser. For those of you familiar with AuthCookie PLEASE Help. I have heard of oddities with IE so I tried Netscape and no differnce. AuthXCookie uses error_header_out to send cookie.. Thanx Chris
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
AuthCookie access denied messages
Before I tackle this myself, has anyone added functionality to AuthCookie so that it will report *why* a user is being asked to login? Currently, if a user enters in a wrong username or password, they just get redirected back to the login form with no explanation. Thanks, --David
Re: AuthCookie access denied messages
David Young wrote on Mon, Aug 20 2001 (12:36:19 -0400): Before I tackle this myself, has anyone added functionality to AuthCookie so that it will report *why* a user is being asked to login? Currently, if a perldoc Apache::AuthCookie /AuthCookieReason cu, -- Toni Andjelkovic [EMAIL PROTECTED]
Re: AuthCookie access denied messages
you can set these in yourself by overwriting
the AuthCookie Response method
you should catch these in your
own subs and send back messages
for instance
in my Auth.pm authen_ses_key sub
[ snip ]
In addition to that, what I found confusing was actually getting authen_ses_key to be
called in the first place, after a failed login attempt.
The stock authen_cred returns data that will be loaded into a cookie only if
authentication is successful. To get authen_ses_key to be called after an
unsuccessful attempt, your authen_cred needs to do this:
if ( check_creds() ) {
# make a ticket, start a session, etc
return $valid_ticket_data;
}
else {
return oops; # make sure we never accept this as a valid cookie!
}
Now authen_ses_key gets called and AuthCookie will set AuthCookieReason to bad_cookie
if you return undef. Also, you now have a chance to set other environment variables.
...Steve
--
Steve van der Burg
Information Services
London Health Sciences Centre
(519) 685-8300 ext 35559
[EMAIL PROTECTED]
Re: AuthCookie access denied messages
David Young wrote:
Before I tackle this myself, has anyone added functionality to AuthCookie so
that it will report *why* a user is being asked to login? Currently, if a
user enters in a wrong username or password, they just get redirected back
to the login form with no explanation.
Thanks,
--David
you can set these in yourself by overwriting
the AuthCookie Response method
you should catch these in your
own subs and send back messages
for instance
in my Auth.pm authen_ses_key sub
if ($checks ne 1 ||$id eq '') {
$r-subprocess_env('AuthCookieReason2', 'does not check or you have
no id');
return '';
}
else {
return $creds[0];
}
then in login.cgi
my $error=$r-prev-subprocess_env('AuthCookieReason2')
|| $r-prev-subprocess_env('AuthCookieReason');
i then just put this erro in as a template param
which handles
my error or else give default 'no cookie one'
hope that helps
also you might wanna try setting
PerlSetVar AuthCookieDebug 3
for longer messages in logs till you get then hang of it
Re: AuthCookie access denied messages
Hi there, On Mon, 20 Aug 2001, David Young wrote: Before I tackle this myself, has anyone added functionality to AuthCookie so that it will report *why* a user is being asked to login? Currently, if a user enters in a wrong username or password, they just get redirected back to the login form with no explanation. It's generally considered a security hole to report things like invalid user id to a user who fails to get a login, because when he finally gets invalid password he knows he's got a valid user id... 73, Ged.
Re: AuthCookie access denied messages
Agreed, however I'd like to at least say The username and/or password you entered was not recognized. From: Ged Haywood [EMAIL PROTECTED] Date: Tue, 21 Aug 2001 00:36:33 +0100 (BST) To: David Young [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: AuthCookie access denied messages It's generally considered a security hole to report things like invalid user id to a user who fails to get a login, because when he finally gets invalid password he knows he's got a valid user id... 73, Ged.
AuthCookie question
Hi, I have set up Authcookie. I modified the sample scripts for my sight. Everything works except when the wrong password is entered. When an invalid user/password is entered, instead of re-displaying the login page, I get a 302 Found error to url http://myhost/LOGIN Any ideas on what I may have wrong? thanks chad Here is a copy of my httpd.conf file # In httpd.conf or .htaccess: PerlModule Sample::AuthCookieHandler PerlSetVar WhatEverPath / PerlSetVar WhatEverLoginScript /login.pl PerlSetVar AuthCookieDebug 3 PerlFreshRestart On # These documents require user to be logged in. Location /members AuthType Sample::AuthCookieHandler AuthName WhatEver PerlAuthenHandler Sample::AuthCookieHandler-authenticate PerlAuthzHandler Sample::AuthCookieHandler-authorize Require valid-user AllowOverride All /Location Location /members/cgi-bin AuthType Sample::AuthCookieHandler AuthName WhatEver PerlAuthenHandler Sample::AuthCookieHandler-authenticate PerlAuthzHandler Sample::AuthCookieHandler-authorize Require valid-user AllowOverride All /Location # These documents don't require logging in, but allow it. FilesMatch \.cgi$ AuthType Sample::AuthCookieHandler AuthName WhatEver PerlAuthenHandler Sample::AuthCookieHandler-authenticate PerlAuthzHandler Sample::AuthCookieHandler-authorize Require valid-user /FilesMatch FilesMatch \.pl AuthType Sample::AuthCookieHandler AuthName WhatEver SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI PerlAuthenHandler Sample::AuthCookieHandler-authenticate PerlAuthzHandler Sample::AuthCookieHandler-authorize Require valid-user /FilesMatch # This is the action of the login.pl script above. Files LOGIN AuthType Sample::AuthCookieHandler AuthName WhatEver SetHandler perl-script PerlHandler Sample::AuthCookieHandler-login /Files Location /perl-status SetHandler perl-script PerlHandler Apache::Status /Location
Re: AuthCookie question
Chad Phillips [EMAIL PROTECTED] said something to this effect on 07/06/2001: Hi, I have set up Authcookie. I modified the sample scripts for my sight. Everything works except when the wrong password is entered. When an invalid user/password is entered, instead of re-displaying the login page, I get a 302 Found error to url http://myhost/LOGIN Any ideas on what I may have wrong? I didn't see any ErrorDocument settings; try setting it: ErrorDocument 401 http://myhost/LOGIN Of course, this will be for the whole virtual server, but whenever someone doesn't authenticate correctly, they'll be redirected to the login page. (darren) PS The sig is randomly generated, and not aimed at you... -- The Feynman Problem 1) Write down the problem. Solving Algorithm 2) Think real hard. 3) Write down the answer.
AuthCookie expansion
Title: AuthCookie expansion modperlers, We have been using AuthCookie (very successfully) for web site login with user accounts held in an Oracle DB. With expansion, what we would now like to do is have one login screen, then, depending on a user attribute's, redirect to a different version of the website. E.g. using opening page: http://www.server.co.uk, if user 1 was of type 'red', they'd be logged in to http://www.server.co.uk/red, whereas user 2, type 'blue' = http://www.server.co.uk/blue. Each sub site would then be a different customised view of the data. Now AuthCookie catches attempts to access unauthorised pages and redirects to a login page. The login form has the destination url as a hidden field and a redirection to this url is performed once the credentials have been verified. What I would like to do is redirect to a home page looked up from the database. The database lookup is trivial but where and how is the best place to do the redirection within the AuthCookie framework ? We are basically looking for a point in the right direction, would this be of use to others if a change was made to AuthCookie ? Ta, --Rich
Re: AuthCookie expansion
RB == Rich Buckley [EMAIL PROTECTED] writes: RB credentials have been verified. What I would like to do is redirect RB to a home page looked up from the database. The database lookup is RB trivial but where and how is the best place to do the redirection RB within the AuthCookie framework ? Make the destination of the login page be your redirect script, which then does the lookup based on the login ID and redirects the user. Either that or use a rewrite rule with the rewrite engine based on user ID and some map that converts user IDs to pages. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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/
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
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, LOC
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: 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, LOC 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: 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
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 Location /CIP AuthTypeSample::AuthCookieHandler AuthNameDarkness PerlAuthenHandler Sample::AuthCookieHandler-authenticate PerlAuthzHandlerSample::AuthCookieHandler-authorize require valid-user /Location Location /Intro AuthTypeSample::AuthCookieHandler AuthNameDarkness PerlFixupHandlerSample::AuthCookieHandler-recognize_user /Location Files LOGIN AuthTypeSample::AuthCookieHandler AuthNameDarkness SetHandler perl-script PerlHandler Sample::AuthCookieHandler-login /Files 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
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
Re: Getting AuthCookie to return a wml page
Delivering text/html to a wap browser will definitely make it choke a bit :-) If you are using the same access mechanism for both web wap access then you have to sniff the client details to work out what to send back. Now you *could* look at the USER_AGENT string of the request and work off of that, but frankly that can get to be a real chore given the increasing diversity of wap browsers. (Yeah, you could match 'Nokia', 'UP' or 'Ericsson' to get most of them) Alternatively, best to look at the Accept content type field in the request, and match on text/vnd.wap.wml for the WAP users. For them, you'll then need to set the header type of any response to be that mime type. I'd have thought $r-content_type() should work, surely. You aren't using header_out() somewhere instead are you (IIRC the Eagle book says used content_type over this) ps: I find the Phone.com UP SDK more informative when dealing with errors in development. Of course, all the real phones deviate from the emulators anyway, but thats another story. pps: out of curiosity, are you relying on the wap gateway to store the cookie on behalf of the wap browser or what ? I was under the impression that not all wap browsers could deal with cookies Tim Fulcher Michael Smith wrote: Dear All, I'm trying to use AuthCookie to return a wml page for those lucky people on wap browsers. I've got it all working nicely for normal web browsers, but am getting errors on wap (and the Nokia Wap Toolkit doesn't tell me very much about why it's an error). One thing that looks a bit suspicious is the Content-type line which comes our as text/html - in fact to be precise it comes out as: Content-Type: text/html; charset=iso-8859-1 I've tried to override this with things like $r-content_type but to no avail. It seems that there's a line in http_protocol.c (line 2667) which is setting this (this response is harcoded there). Surely I ought to be able to override this ... in which case the obvious question is, how? Cheers Mike http://www.iii.co.uk Interactive Investor International is a leading UK Internet personal finance service that provides individuals with the capability to identify, compare, monitor and buy online a number of financial products and services. Interactive Investor Trading Limited, a subsidiary of Interactive Investor International plc, is regulated by the SFA.
Getting AuthCookie to return a wml page
Dear All, I'm trying to use AuthCookie to return a wml page for those lucky people on wap browsers. I've got it all working nicely for normal web browsers, but am getting errors on wap (and the Nokia Wap Toolkit doesn't tell me very much about why it's an error). One thing that looks a bit suspicious is the Content-type line which comes our as text/html - in fact to be precise it comes out as: Content-Type: text/html; charset=iso-8859-1 I've tried to override this with things like $r-content_type but to no avail. It seems that there's a line in http_protocol.c (line 2667) which is setting this (this response is harcoded there). Surely I ought to be able to override this ... in which case the obvious question is, how? Cheers Mike http://www.iii.co.uk Interactive Investor International is a leading UK Internet personal finance service that provides individuals with the capability to identify, compare, monitor and buy online a number of financial products and services. Interactive Investor Trading Limited, a subsidiary of Interactive Investor International plc, is regulated by the SFA.
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
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. Files LOGIN AuthType Apache::AuthCookieHandler AuthName Apollo SetHandler perl-script PerlHandler Apache::AuthCookieHandler-login /Files 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
