Hi,
I'm having a bit of trouble authenticating users. The script I have works, but only a
couple of times before it just sends out 401 without prompting the user for their
details. We have mod_perl 1.99_05 installed, we don't want to upgrade as we would have
more applications to upgrade than
Stephen Hardisty wrote:
Hi,
I'm having a bit of trouble authenticating users. The script I have works, but only a
couple of times before it just sends out 401 without prompting the user for their
details. We have mod_perl 1.99_05 installed, we don't want to upgrade as we would have
more
Good afternoon,
On 27/8/03 at 9:37 AM -0400, Michael [EMAIL PROTECTED] wrote:
The reason this question is mod_perl related is that he is doing the
initial authentication using mod_perl, and is creating a cookie based
ticket. But he wants that ticket to also be accepted by a
non-mod_perl enabled
Good afternoon,
On 27/8/03 at 9:45 AM -0400, Michael [EMAIL PROTECTED] wrote:
Any other suggestions?
I'd think you'd want to have the same authentication process for both, and a
shared database (or something) to store the session data. Have the front-end
do the login part, pass the client
Good morning,
On 26/8/03 at 8:26 PM +0200, Thomas Klausner [EMAIL PROTECTED] wrote:
Hi!
On Die, Aug 26, 2003 at 09:06:05 +1000, Charlie Garrison wrote:
I need to protect resources in both the static (proxy) front-end and
the mod_perl back-end. I have been using standard http authentication
On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said...
The second one, Cookie Authentication with MySQL, looks like a very good
option, except for two issues. Fist, it doesn't support the 'require group...'
directive. And second, it doesn't appear to cache mysql connections so I am
Quoting Michael [EMAIL PROTECTED]:
On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said...
The second one, Cookie Authentication with MySQL, looks like a very good
option, except for two issues. Fist, it doesn't support the 'require
group...'
directive. And second, it doesn't appear
related is that he is doing the initial
authentication using mod_perl, and is creating a cookie based ticket. But he
wants that ticket to also be accepted by a non-mod_perl enabled server (ie a
front end proxy).
Thanks for the clarification. And the requirement for something that works in
both modperl
Good afternoon,
On 27/8/03 at 12:05 AM -0400, Michael [EMAIL PROTECTED] wrote:
The second one, Cookie Authentication with MySQL, looks like a very
good option, except for two issues. Fist, it doesn't support the
'require group...' directive. And second, it doesn't appear to cache
mysql
Hi there,
On Wed, 27 Aug 2003, Charlie Garrison wrote:
Do you also write the apache module for the frontend server? I'm very
competent at perl, but not competent enough to write an apache module.
It's not so hard. There's a skeleton module in the Apache sources for
you to start with, take a
the initial
authentication using mod_perl, and is creating a cookie based ticket. But he
wants that ticket to also be accepted by a non-mod_perl enabled server (ie a
front end proxy).
So the database connection has to persist from the mod_perl authentication
scheme to the backend software
, but not competent enough to write an apache module.
Any other suggestions?
I'd think you'd want to have the same authentication process for both, and a
shared database (or something) to store the session data. Have the front-end
do the login part, pass the client to the backend, which discovers
authentication which works
pretty well except for not allowing a proper logout function and some caching
issues which result in occasional false FORBIDDEN responses. Since a proper
logout has become an important requirement, I am looking for other solutions.
Since I need the user credentials
Hi!
On Die, Aug 26, 2003 at 09:06:05 +1000, Charlie Garrison wrote:
I need to protect resources in both the static (proxy) front-end and the
mod_perl back-end. I have been using standard http authentication which works
pretty well except for not allowing a proper logout function and some
We recently upgraded our webserver from
Apache 1.3.6 / modperl 1.19
to
Apache 1.3.27 / modperl 1.27
We use a .htaccess file in a directory to have a modperl script do
authentication for directory access (for downloading files, etc.). It
also redirects the user from http to https if he does
Quoting Carl Brewer [EMAIL PROTECTED]:
Forgive me for asking yet another fundamentally basic question.
I'm cutting a web app over from PHP to mod_perl 2, and
am wondering how 'best' (for which there are many flavours ...)
to handle authentication.
At present I've knocked up a site
Cees Hek wrote:
[chomp]
Thanks Cees, that's exactly what I needed :) My stuff is all completely
generated by scripts where I need access control, but I certainly
see the use for controlling static entity access.
Carl
Forgive me for asking yet another fundamentally basic question.
I'm cutting a web app over from PHP to mod_perl 2, and
am wondering how 'best' (for which there are many flavours ...)
to handle authentication.
At present I've knocked up a site that does auth via a
form and state tracking
hi all...
buried within perl.com this week is my latest article
http://www.perl.com/pub/a/2003/07/08/mod_perl.html
which covers how to use Apache 2.1 authentication from Perl. one of
the biggest benefits of Apache 2.1 auth over Apache 2.0 (or even 1.3)
is the ease at which it opens up
I tried to modify the Web agenda/calendar
chronos (http://chronoss.sourceforge.net) in such a way that everyone can
look at the calendar without authentication but changes need basic
authentication. In other words, URLs like
http://.../chronos?action=showday;
should go through without
Meik Hellmund wrote:
I tried to modify the Web agenda/calendar
chronos (http://chronoss.sourceforge.net) in such a way that everyone can
look at the calendar without authentication but changes need basic
authentication. In other words, URLs like
http://.../chronos?action=showday
Perrin Harkins wrote (in a discussion with Michael L. Artz):
Well, I figured that the AuthenHandler already parsed the
authentication cookie and declared it valid, so I didn't really see
a point the in doing it at the beginning of every script. $r-user
just seemed more intuitive to me
to a user? My
session table currently looks like [user_id, session_key, session_data,
login_time, last_access_time]. I guess I am currently using the session
table to be more of an authentication table, i.e. if you give me a good
user_id/session_key ticket that matches what is in the database.
I
plus proxy), which is kind of popular now, one can
set it up in the light server to protect static content.
Peter
- Original Message -
From: Michael L. Artz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2003 6:47 PM
Subject: Re: Authentication design
Well, sorta. I am
a matter of 'niceness'?
I'm not sure what you mean.
Putting the session/user stuff
in AuthenHandler and then setting the $r-user makes it clear where the
authentication takes place. All other handlers just check if $r-user is
set and need not to bother with sessions and stuff?
Are you asking why
of the form
they are filling out.
My
session table currently looks like [user_id, session_key, session_data,
login_time, last_access_time]. I guess I am currently using the session
table to be more of an authentication table, i.e. if you give me a good
user_id/session_key ticket that matches
Hmm, I see now. I don't really care about users who aren't logged in,
so I don't know that there is a need to store session data for them.
I guess my pattern is:
within PerlAuthenHandler
-Check to see if there are passed user/password params. If so,
validate params against user/pass in
Jonathan Gardner wrote:
It sounds like you are mixing HTTP-level authentication with
application-level
authentication.
Well, sorta. I am actually using a custom module very similar to the
one found in the cookbook (and AuthCookie, I think), i.e. create a
PerlAuthenHandler that sets the custom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday 03 June 2003 18:59, Michael L. Artz wrote:
I am trying to design/implement a fairly simple authentication scheme
using cookies and such, but wanted to air my design questions before I
run into too many issues.
It sounds like you
On Tue, 2003-06-10 at 21:47, Michael L. Artz wrote:
I thought that this was a good way to go since I could protect my entire
application with a single module and a couple lines in the config file,
as opposed to bundling that authentication code into the beginning of
*every* registry script
Perrin Harkins wrote:
I'm not certain it won't work to use $r-user, but I don't see the point
when you already have a unique identifier in the cookie.
Well, I figured that the AuthenHandler already parsed the authentication
cookie and declared it valid, so I didn't really see a point
On Tue, 2003-06-10 at 23:43, Michael L. Artz wrote:
Well, I figured that the AuthenHandler already parsed the authentication
cookie and declared it valid, so I didn't really see a point the in
doing it at the beginning of every script. $r-user just seemed more
intuitive to me.
Well, I'm
I am trying to design/implement a fairly simple authentication scheme
using cookies and such, but wanted to air my design questions before I
run into too many issues.
I would like the site to be almost entirely publicly accessible, however
if you log in you get special options in addition
Hi Michael --
My question basically centers around the best way to protect
the only
if you login pages. I was thinking of putting them in their own
directory and protecting them with a tiny PerlAuthzHandler,
which would
scatter scripts of the same nature in two separate places (i.e.
I am fairly new to mod_perl/apache, having grown up with OpenACS and
AOLServer. I have read all of the docs on the web site (I think) and
had a whole authentication/authorization scheme planned out using
Apache::AuthCookie and Apache::Session. I was just put in charge of a
beta web
Michael L. Artz wrote:
I am fairly new to mod_perl/apache, having grown up with OpenACS and
AOLServer. I have read all of the docs on the web site (I think) and
had a whole authentication/authorization scheme planned out using
Apache::AuthCookie and Apache::Session. I was just put in charge
Title: Message
Hi,
I'm writing my own
authentication module that uses Oracle and special encryption to handle
passwords, it uses pretty much the same code as AuthDBI except for a few
changes.
Everything was
running smoothly until I tried to make a mod_perl handler be the 401
Scott Alexander wrote:
Hi,
I'm using Apache-AuthCookie-3.04 for authentication
I have a protected directory with 10 sub directories, one directory needs
to be open to any user.
I could write 10 Directory /usr/local/systems/work/directory_1 or use a
PERL section in the conf file to create the 10
This might be a bit OT, but since I've read somewhere on apache.org that
Apache2 was using the same regex engine as Perl 5's...
So I'm under the impression that with Apache2 you could do something
like:
DirectoryMatch ^/usr/local/systems/works/(?!open/)
# your auth handler goes here
Hi,
I'm using Apache-AuthCookie-3.04 for authentication
I have a protected directory with 10 sub directories, one directory needs
to be open to any user.
I could write 10 Directory /usr/local/systems/work/directory_1 or use a
PERL section in the conf file to create the 10 directory directives
On Fri, 13 Dec 2002 20:19:55 -0800 (PST), Bill Moseley wrote:
Hi Bill
On Sat, 14 Dec 2002, Ron Savage wrote:
Under Apache V 1/Perl 5.6.0 I could not get the
Apache::AuthCookieURL
option working which munged URLs without requiring cookies.
I thought the problem was that Apache::AuthCookie was
On Thu, 12 Dec 2002 14:29:16 -, Peter Werner wrote:
hi all
Hi Peter, et al
[snip]
i suppose it really depends on what you are developing, but take
heed. i
fully understand why cookie based authentication may be
unacceptable, but
consider maintainability and (long-term) scalability when
On Sat, 14 Dec 2002, Ron Savage wrote:
Under Apache V 1/Perl 5.6.0 I could not get the Apache::AuthCookieURL
option working which munged URLs without requiring cookies.
I thought the problem was that Apache::AuthCookie was redirecting to your
login scrip on logout instead of displaying your
Ron Savage wrote:
On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote:
[snip]
Some of us are trying to implement authentication/login/logout where,
if at all possible, cookies are not to be used. A cookie-free
discussion would be most welcome.
I've done a bit of preliminary
hi all
www.wgsn.com is a subscription based service that doesn't use cookies for
authentication. we use basic auth.
I would like to share what i consider how not to implement cookie-free
authentication.
there are three tiers to our website
tier 1 is apache with mod_perl doing authentication
I am using a homegrown subclass of AuthCookieDBI for authentication. So far so good.
But I have a problem that I hope someone can offer guidance on.
For now I have the auth set to expire after a certain amount of time. After the
expiration, the next time the user clicks, the login form comes
I am also interested in this patch, as we encounter lots of problems with
some POSTed forms over here.
I just uploaded a new version with a fix to CPAN:
The URL
ftp://ftp.dev.ecos.de/pub/perl/ntlm/Apache-AuthenNTLM-0.23.tar.gz
has entered CPAN as
file:
An: Gerald Combs [EMAIL PROTECTED], [EMAIL PROTECTED]
Kopie:
Thema: Re: NTLM Authentication patch
We recently installed AuthenNTLM where I work, and ran into the POST
problems described in the thread at
http://marc.theaimsgroup.com/?t=10317736546r=1w
We recently installed AuthenNTLM where I work, and ran into the POST
problems described in the thread at
http://marc.theaimsgroup.com/?t=10317736546r=1w=2
After looking through a couple of network traces I think I've found the
problem. It appears that after IE authenticates via
earlier in
the keepalive session, AuthenNTLM validates the request and a POST with no
accompanying POST data gets passed to the server.
Attached is a patch against the 0.21 release that fixes this behavior (in
our environment, at any rate). I know very little about NTLM
authentication and mod_perl
Hello,
I have a search engine that students can use to search for old exam
papers. The papers can be served up if the student is accessing the
papers from inside the university. If they are outside the university
then they authenicate through Auth::LDAP.
Unfortunately staff are asking for
I have a mod_perl cgi script that I would like to get the username from
the Apache server. The apache server successfully authenticates the
client using Apache::AuthenSmb.
How do I get this environment variable (the username) from apache into a
variable in the perl script.
Thanks,
Brett
At 09:55 28.08.2002, Brett Hales wrote:
I have a mod_perl cgi script that I would like to get the username from
the Apache server. The apache server successfully authenticates the
client using Apache::AuthenSmb.
How do I get this environment variable (the username) from apache into a
variable in
. Or
maybe Apache::AuthenSmb doesn't set $r-user at all. Are you even nsure the
authentication is working?
--
Per Einar Ellefsen
[EMAIL PROTECTED]
However, if the structure were
http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas,
say, with the number being the session ID, the URL then is hackable
within that (good) definition.
Yes, however there are quite a number of issues with bookmarks and
search engines... But
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain. How are you going to
get some people to send the credentials and some
? That
would be another good option.
I thought you meant that you wanted the same location to be
accessed by different people with/without passwords. You
should be able to put the authentication directives in a
LocationMatch container in this case. Another approach
would be to use mod_rewrite to map
On Mon, Jul 01, 2002 at 10:30:36AM +0100, Jean-Michel Hiver wrote:
browser sent the credentials, or leave $ENV{REMOTE_USER} undef
otherwise, without sending a 401 back.
I didn't think a browser would send authentication unless the server
requested it for an authentication domain
Thanks to the list and two days of hard work, I have my optional HTTP
authentication thingie working :-)
Basically here is how it looks in my apache config file:
# This method handler ensures that users must enter their credentials
# for any URI which looks like /foo/bar/login.html
Hi there,
On 30 Jun 2002, Randal L. Schwartz wrote:
What? The EU is going to make cookies *illegal*? I highly doubt this.
There is already EU legislation which might make the use of cookies suspect.
It concerns, for example, the monitoring of individual keyboard operators
to measure their
Jean-Michel Hiver [EMAIL PROTECTED] writes:
However, if the structure were
http://bigmegamarket.com/index.pl/56765454151/grocery/fruits/bananas,
say, with the number being the session ID, the URL then is hackable
within that (good) definition.
Yes, however there are quite a number
to be protected, i.e.
/foo/bar/
/foo/bar/print.html
/foo/bar/dc.xml
/foo/bar/rss100.rdf
But some others need to, like:
/foo/bar/properties.html
/foo/bar/contents.html
/foo/bar/move.html
etc.
I want to use HTTP authentication for that, but of course I cannot
password protect the whole site, because
Oh, I don't know, I think the poster was asking about how to produce this
effect with mod_perl. He wants to know *whether* a login was provided, even
on a *non-protected* page. That would let you say (while serving any old
page):
if( $ENV{REMOTE_USER} eq 'admin' ) {
$r-print('Yo,
and use the provided hash to store the login information. I have
read the whole portion of the eagle book dedicated to authentication /
authorization before posting my crack-smoked question to the list ;-)
Unfortunatly:
* For political reasons and compliance with future european legislation
I cannot
encoding session IDs on URIs would be really
Jean-Michel bad... users needs to be able to 'hack' the URIs without f***ing their
Jean-Michel sessions!
Why is a user hacking their URLs?
Jean-Michel Therefore I have to use HTTP authentication...
Even though the user/password is transmitted
/ is cool,
http://bigmegamarket.com/index.pl?id=231223412sid=56765454151 is not.
Again it doesn't always make implementation easy :-/
Jean-Michel Therefore I have to use HTTP authentication...
Even though the user/password is transmitted *in the clear* on
*every single hit*, because you can't
Please check that the idea of this kind of authentication is to encrypt the
ticket, instead of a plain session ID. If cookie is not available, having
it on URI is a good idea. (Then one needs to have all links in a relative
manner; see the Cookbook). Cookie itself does not make a secure session
On Sun 30-Jun-2002 at 10:47:26AM -0700, Peter Bi wrote:
Please check that the idea of this kind of authentication is to encrypt the
ticket, instead of a plain session ID. If cookie is not available, having
it on URI is a good idea. (Then one needs to have all links in a relative
manner; see
that comes after authentication runs under
Apache::Registry.
Unfortunately, I might need the script to run under mod_cgi... I
couldn't find how to tell the apache server to set environmental
variables in the mod_perl pocket reference, anyone has got an idea?
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND
Jean-Michel Hiver [EMAIL PROTECTED] writes:
Why is a user hacking their URLs?
I can answer that. http://www.useit.com/alertbox/990321.html
cite
* a domain name that is easy to remember and easy to spell
* short URLs
* easy-to-type URLs
* URLs that visualize the site
Hi, Jean-Michel: the official way to retrieve the remote user name under
Basic Authentication is to call for $r-connect-user(), or $r-user() in
mod_perl 2.0, I think. With a ticket authentication, one gets the user name
in the same way only AFTER the access control phase, because it is simulated
From: Jean-Michel Hiver [EMAIL PROTECTED]
I *CANNOT* use cookies nor URIs for any kind of session tracking.
Otherwise I don't think I would have posted this message to the list in
the first place :-)
I agree that HTTP Basic authentication is totally and uterly ugly, but I
am going
I need to decide who has access based on the URI. I guess this means I
can't use Apache's Basic auth module, since I can't dynamically set
require. Does the cookbook have a code sample of checking the password for
basic authentication?
-Todd
On Mon, 20 May 2002, Geoffrey Young wrote
That makes sense. I can't use mod_auth because I can't set Require. I'm
using Basic authentication and text based password files. Unfortunately, I
can't find an Apache::Auth* module that handles basic authentication
against text files. Did I miss it somewhere?
Thanks.
-Todd
On Mon, 20 May
), then you can't run any
authentication
handler - mod_auth, mod_perl, or otherwise. Apache core requires the Require
directive to
be set to something before it will even try to run the authen/authz phases of the
request.
so, you may be out of luck and need to resort to the CGI tricks of yore
Todd Chapman wrote:
Can dir_config be used to set 'require' in an authentication handler?
no. dir_config() provides access to a mod_perl specific table of variables, not
generic
Apache configuration directives.
there is no API for setting the Require directive - it needs to be in your
. if a URI comes in that you want to allow _without_ checking
the
password just call
$r-set_handlers(PerlAuthenHandler = [\OK]);
which will essentially short-circuit Apache's default authentication mechanism before
mod_auth gets the chance to step in. you could do this from a PerlAccessHandler or (I
Todd Chapman wrote:
That makes sense. I can't use mod_auth because I can't set Require.
well, if you're saying that you don't have the ability to set the Require directive at
all
(as in you don't have access to edit httpd.conf), then you can't run any
authentication
handler - mod_auth
A remark: in many cases, the authentication against the password file can be
replaced by verifying valid FTP/Telnet login to localhost, not only
because the password (shadow) file is usually not avialble for Apache
account but also secure. In the ticketing system, the FTP/Telnet
authentication
Can dir_config be used to set 'require' in an authentication handler?
I would then return DECLINED do that Apache's Basic auth handler would do
the heavy lifting of checking the password.
Thanks!
-Todd
I have a requirement to protect all pages on a website, and to only
allow in users with a valid user id, password, client certificate and
recognised IP.
I know this is asking a lot, but I would appreciate an
overview/recommendation of approaches that are 1st safe, and 2nd fast.
I think
And then he reads on p360 that there are tantalising recipes in chapter
13...
I would still appreciate the lists thoughts and experience.
-Original Message-
From: Jeff AA [mailto:[EMAIL PROTECTED]]
Sent: 14 May 2002 09:07
To: [EMAIL PROTECTED]
Subject: mod_perl: User Authentication
Greetings,
I have written a mod_perl authentication module and I am trying to figure
out how to get it to protect top level directories. I have it setup in such
a way that it calls lower level directories to display the login form and
when I protect the top level directory it just loops
: Wednesday, April 17, 2002 6:21 PM
Subject: Re: mod_perl Basic Authentication problem using PerlAuthenHandler
Jason wrote:
In httpd.conf i have
Location /~jter
[snip]
Deny from all
/Location
[snip]
It warns to the log file and returns
Deny from all
/Location
And my module is
package ApacheAuthentication;
#use strict;
use Apache::Constants qw(:common);
use Apache::URI;
use Apache::File;
sub handler {
my $r = shift;
# get user's authentication credentials
my ($res, $sent_pw) = $r
database to hold the user information
used for authentication. How can I configure the proxy (which doesn't have
mod_perl) to authenticate against the back end?
My first thoughts were to use mod_proxy to forward requests for
/protected/login to the backend, where the authentication will be done
the user information
used for authentication. How can I configure the proxy (which doesn't have
mod_perl) to authenticate against the back end?
My first thoughts were to use mod_proxy to forward requests for
/protected/login to the backend, where the authentication will be done.
Then, just redirect
My first thoughts were to use mod_proxy to forward requests for
/protected/login to the backend, where the authentication will be
done.
Then, just redirect the request to another URL behind /protected. The
authentication information should be passed as part of the request,
should
I am attempting to redirect certain users during the authentication phase
to support password expiration management. I am not having success
building it directly into the authentication module and think it may be
perhaps that the internal REDIRECT constant is ignored if given outside of
a content
Christian Gilmore wrote:
I am attempting to redirect certain users during the authentication phase
to support password expiration management. I am not having success
building it directly into the authentication module and think it may be
perhaps that the internal REDIRECT constant
to redirect certain users during the authentication phase
to support password expiration management. I am not having success
building it directly into the authentication module and think it may be
perhaps that the internal REDIRECT constant is ignored if given outside of
a content handling phase
Hi!
I have SunOS 5.8 machine and apache 1.3.22 with mod_perl 1.26 on it.
Now I'm trying to install in apache authentication against LDAP server.
So I installed AuthenLDAP module. But when I try to go to the directory
in browser, apache says - Internal Server Error, and in error.log file
I see
At 17:21 13.02.2002 -0600, you wrote:
File::Spec is in included with the standard perl mods I believe
so dependencies shouldn't be a problem.
I see. You're right, this is actually much nicer!
Sorry for the misinformation. On debian it return : also. I made a
mistake checking it.
But
Hi Darren
Would you submit the current version? If you need help with the
Documentation just let me know. For the makefile, I do not have any
experience.
Marcel
Am Mittwoch den, 13. Februar 2002, um 21:01, schrieb darren chamberlain:
Quoting Marcel Weber [EMAIL PROTECTED] [13 Feb-02
Quoting Marcel Weber [EMAIL PROTECTED] [12 Feb-02 16:15]:
I don't get the point why it did not work the other way round,
but now everything is just fine now :
Make it a little more generic:
package Apache::MultiAuthen;
use strict;
use Apache::Constants qw(:common);
sub handler {
my $r =
shouldn't stacked handlers be the right solution here? are stacked auth
handlers not allowed or something?
aaron
On Wed, 2002-02-13 at 09:02, darren chamberlain wrote:
Quoting Marcel Weber [EMAIL PROTECTED] [12 Feb-02 16:15]:
I don't get the point why it did not work the other way round,
Quoting Aaron Ross [EMAIL PROTECTED] [13 Feb-02 09:21]:
shouldn't stacked handlers be the right solution here? are
stacked auth handlers not allowed or something?
Assuming your mod_perl has been built with them, then, yes, that's
probably a better solution. But I had a fun 15 minutes writing
He wants to check a 'handler' return value.
shouldn't stacked handlers be the right solution here? are stacked auth
handlers not allowed or something?
aaron
On Wed, 2002-02-13 at 09:02, darren chamberlain wrote:
Quoting Marcel Weber [EMAIL PROTECTED] [12 Feb-02 16:15]:
I don't get
and let
mod_auth take care of setting AUTH_REQUIRED for you (since the perl
handlers generally run before the Apache C modules). however, with
Apache::AuthFoo, the AUTH_REQUIRED stuff is generally compiled in,
which means that the authentication chain is terminated prematurely.
the solution darren
the only problem is that,
for the PerlAuthenHandler and PerlAuthzHandler the first handler to
return an Apache error code (anything other than OK, DECLINED, or
DONE) terminates the chain. which is generally fine, except when you
want to return AUTH_REQUIRED and note_basic_auth_failure().
1 - 100 of 296 matches
Mail list logo
