Re: about request route
Hello,
MP does not by default include a routing engine like Dancer or Mojo or
other frameworks.
There are routing engines available (but I'm not very familair with them).
For a pure MP option, see this example from something I've done:
$base_uri = "/app/"
uri = /app/type//domain/dns-api.org/
my $uri = $r->uri();
> # Remove the base uri from the uri
> $uri =~ s/^$base_uri//g;
> # Split the components out by '/'
> my @components = split(/\//, $uri);
> # Take all the components and make the odd ones the names and the
> even ones
> # the values in the CGI query object
> while (@components)
> {
> $components[1] =~ s/\|/\//g;
> $q->param(-name => shift(@components), -value =>
> shift(@components));
> }
> }
*Lathan Bidwell*
Web Programmer
Division of Integrated Marketing & Communication
Andrews University
269-471-6313
*office*www.andrews.edu
"Seek Knowledge. Affirm Faith. Change the World."
On Mon, Aug 7, 2017 at 7:18 AM, 风河 <m...@fenghe.org> wrote:
> Hi,
>
> for this like request:
> curl http://dns-api.org//dns-api.org
>
> in Dancer we could write:
>
> get '/:type/:domain/?' => sub {
>
> my $rtype = params->{ 'type' };
> my $domain = params->{ 'domain' };
>
>
> But in a MP handler, how could we get the similiar result, treating
> request path as GET/POST arguments?
>
> thanks.
>
Re: [Slightly OT] Apache::AuthCookie and mod_perl version 1.x
Running it on Apache 2.2 and 2.4, so would be fine for you to discontinue 1.x. Thanks for the good work. *Lathan Bidwell* Web Programmer Division of Integrated Marketing & Communication Andrews University 269-471-6313 *office*www.andrews.edu "Seek Knowledge. Affirm Faith. Change the World." On Mon, Jul 31, 2017 at 9:14 PM, 风河 <m...@fenghe.org> wrote: > Most are mobile App interfaces. > > On Tue, Aug 1, 2017, at 09:07 AM, Jie Gao wrote: > > * 风河 <m...@fenghe.org> wrote: > > > > > Date: Tue, 1 Aug 2017 08:57:29 +0800 > > > From: 风河 <m...@fenghe.org> > > > To: modperl@perl.apache.org > > > Subject: Re: [Slightly OT] Apache::AuthCookie and mod_perl version 1.x > > > X-Mailer: MessagingEngine.com Webmail Interface - ajax-917c8476 > > > > > > We have a lot of servers running under mp2 and httpd2.2 :) > > > > > > What a nice surprise for mod_perl then. :-) > > > > > > -Jie > > > > > > > On Tue, Aug 1, 2017, at 05:51 AM, Randolf Richardson wrote: > > > > I don't know of anyone who uses Apache HTTPd v1.x or mod_perl > > > > version 1.x anymore. With mod_perl2 support added recently for > > > > Apache HTTPd v2.4 it seems that earlier versions of mod_perl2 are > > > > gradually being upgraded too (including my systems, of which I only > > > > have a few older ones to upgrade from v2.2 in the near future). > > > > > > > > It seems to me that while Apache HTTPd v2.2 is still quite popular > > > > and continues to be very relevant, I suspect that anything earlier > > > > than v2.2 is also probably not a major concern. Also of interest is > > > > the "end of life" final release status of Apache HTTPd v2.2, for > > > > which you can read the official announcement, here: > > > > > > > > Apache httpd 2.2.34 Released (End-of-Life); final release > > > > http://www.apache.org/dist/httpd/Announcement2.2.html > > > > > > > > In summary, I have no need for Apache HTTPd v1.x since I've long > ago > > > > upgraded to newer v2.2 and v2.4, and so from my perspective I don't > > > > see any need to continue maintaining modules for v1.x (with an > > > > exception being paying customers who won't/can't upgrade from v1.x). > > > > > > > > By the way, thanks for the great work you've put into the > > > > Apache2::AuthCookie module (and its earlier incantations). > > > > > > > > > Hi folks. > > > > > > > > > > Sorry for this slightly off topic thread, but in the past > announcements > > > > > about AuthCookie were typically made to this list. > > > > > > > > > > I'm the maintainer of Apache::AuthCookie (and Apache2::AuthCookie) > and > > > > > am wondering if there are any people out there still using > > > > > Apache::AuthCookie under mod_perl version 1.x (and as such apache > 1.x)? > > > > > > > > > > Given that apache 1.3.42 was the final release of Apache 1.3, > which was > > > > > way back in 2010, I am hoping that everyone has moved on to Apache > 2.x > > > > > long ago. > > > > > > > > > > As a result, I would like to formally drop support for Apache 1.3 > from > > > > > future versions of Apache::AuthCookie. This would allow me to > clean up > > > > > the dist a bit, and be able to publish a consistent set of > dependencies > > > > > in META.* in the dist. > > > > > > > > > > If you really require Apache::AuthCookie under apache 1.3 at this > point, > > > > > you can get a previous version of AuthCookie from backpan to > address that. > > > > > > > > > > If you really do need AuthCookie and getting it from backpan is a > > > > > problem for you, please let me know. > > > > > > > > > > Thanks! > > > > > > > > > > Regards, > > > > > Michael Schout > > > > > > > > > > > > Randolf Richardson - rand...@inter-corporate.com > > > > Inter-Corporate Computer & Network Services, Inc. > > > > Beautiful British Columbia, Canada > > > > http://www.inter-corporate.com/ > > > > > > > > > > > > > >
Re: Recommended Linux distribution for LAMP/mod_perl
We went through a bit of an tricky patch when Ubuntu prematurely switched from Apache 2.2 to 2.4 (with major changes needed for mod_perl to work), like 6-12months before it was ready. But otherwise, I have not had any major issues with ubuntu and apache/mod_perl. *Lathan Bidwell*Web Programmer Division of Integrated Marketing & Communication Andrews University 269-471-6313 *office*www.andrews.edu "Seek Knowledge. Affirm Faith. Change the World." On Mon, Oct 3, 2016 at 1:35 PM, Dr James Smith <j...@sanger.ac.uk> wrote: > We tend to now use Ubuntu LTS set ups for our webservers - currently a mix > of 12.04, 14.04 and 16.04 depening on which part of the production cycle we > are on (yes we have at least 60 for approx 120 different websites)... > > On 03/10/2016 18:09, John Dunlap wrote: > > You're going to be better off with Debian than you will be with CentOS > because Debian actually ships with precompiled mod_perl packages. > > On Mon, Oct 3, 2016 at 1:08 PM, daniel.axtell <daniel.axt...@snet.net> > wrote: > >> I've been trying to migrate a site with a lot of Perl legacy code running >> under Apache 2.2 and mod_perl. The server I was migrating to uses CentOS >> 7, and the default Apache 2.4 and perl 5.16 seem unusually difficult to >> configure. I'm not even able to get CGI scripts to run. In the past I've >> built Perl, Apache and mod_perl from source, but that seems like a lot of >> unnecessary work. Ideally I'd like to use the stock Apache and Perl from >> the distribution, and just install CPAN modules, data and config files and >> go. I'm curious if people here find a particular Linux distribution Perl >> and mod_perl friendly, as the RedHat and CentOS distributions seem pretty >> hostile. CentOS 7 has a third-party module of mod_perl 2.0.8 but if I >> can't get CGI working correctly I don't really trust it. >> >> Should I just assume building everything in the LAMP stack from source is >> the way to go? >> >> Dan >> > > > > -- > John Dunlap > *CTO | Lariat * > > *Direct:* > *j...@lariat.co <j...@lariat.co>* > > * Customer Service:* > 877.268.6667 > supp...@lariat.co > > > > -- The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a company > registered in England with number 2742969, whose registered office is 215 > Euston Road, London, NW1 2BE. >
Re: random token re-used in subsequent requests
Is it possible that its not a problem of the rand, but a problem of the ||= ? Try debugging the value before you set it. It could be a scoping issue where the old value stays in the variable and then ||= doesn't overwrite it. *Lathan Bidwell* On Wed, May 18, 2016 at 9:08 AM, Vincent Veyron <vv.li...@wanadoo.fr> wrote: > On Wed, 18 May 2016 09:12:17 +0200 > André Warnier <a...@ice-sa.com> wrote: > > > Maybe you can try a BEGIN block. If I remember correctly, under mod_perl > (if you run under > > "registry" to keep the compiled cgi-bin in memory), a BEGIN block should > be run only once, > > when the script is first compiled (by this child). > > Tried that, no dice. And I checked the code on an eeepc, it generates > thousands of unique keys no problem, it's just that one server :-( > > Well, giving up for now. Thank you for your help. > > > -- > Bien à vous, Vincent Veyron > > https://libremen.com > Logiciels de gestion, libres >
Re: question on Apache2_4::AuthCookie
> > Hi. > I have (a long time ago) created an AAA module based originally on > Apache2::AuthCookie (a copy and rewrite, not a sub-class). Now I need to > adapt this to Apache 2.4. > I have read all the docs at > https://metacpan.org/source/MSCHOUT/Apache-AuthCookie-3.24/lib/Apache2_4/AuthCookie.pm, > and followed the related correspondence on this list. > My problem is that I would like to keep a single perl source, for both > Apache 2.2 and Apache 2.4. > As far as I can tell so far, this should not be a big problem, except for > the following difference : > > In the Apache 2.2 version, I have this statement : > > use Apache2::Const -compile => qw(:common :http :methods :override :proxy); > > and in the Apache 2.4 version, I must have this statement or it will not > compile : > > use Apache2::Const -compile => qw(:common :http :methods :override :proxy > AUTHZ_GRANTED AUTHZ_DENIED AUTHZ_DENIED_NO_USER); > > I'm not very familiar with require vs use, but could you use a begin block, Apache2::ServerUtil::get_server_version() and then if/else based on the version number? Lathan Bidwell > (That is because these new AUTHZ_* constants must be used in the new > "AuthzProvider" subs). > > I could of course hack the values of these constants under 2.4, and use > their values directly in my module, but that is rather "inelegant". > > My question is thus : would there be a way to make the import of these > constants conditional on the Apache version the module is running under ? > (In other words e.g. define them with value 0 initially (for Apache 2.2, > since they are never used there), and override them if under Apache 2.4 ? > > Or, to put this another way : imagining that there are already some > servers, currently running Apache 2.2 with, say, mod_perl 2.0.7, and on > which the current (2.2-only) version of my Auth module is running. > If I ever update these servers with the latest (2.4-compatible) version of > my module, including the above extra imported constants, that updated > module will not compile anymore on those systems (because these constants > are not defined there). > Is there a way to avoid this incompatibility ? > > I tried to phrase the above as clearly as possible, but if it is still > confusing, I can try again.. > > Thanks > >
Re: Apache 2.4: scope of PerlAddAuthzProvider
You are correct, the new setup thinks of it as setting up global AuthZ handlers. Make sure to name the provider with a good identifier (i.e.: thisAppUser, GlobalLoginUser, ) A great many people would benefit from updating the documentation on these changes. But I think people are focusing on making sure it builds properly on different environments. Lathan On Wed, Apr 22, 2015 at 3:37 AM, Jie Gao j@sydney.edu.au wrote: OK, I suppose I can add the provider globally, but not actually start to use it until I call the module within a container. And it should be PerlAddAuthzProvider user My::MyAuth::AuthCookie-authz as well. Regards, Jie * Jie Gao j@sydney.edu.au wrote: Date: Wed, 22 Apr 2015 17:23:10 +1000 From: Jie Gao j@sydney.edu.au To: modperl@perl.apache.org Subject: Apache 2.4: scope of PerlAddAuthzProvider User-Agent: Mutt/1.5.21 (2010-09-15) Hi When I put the following line within a Location section: PerlAddAuthzProvider user My::MyAuth::AuthCookie-authen I get an error: AH00526: Syntax error on line 545 of /usr/local/httpd-2.4.12/conf/httpd.conf: PerlAddAuthzProvider not allowed here . But if I put it outside the container, it'll apply globally to everything and that is not what I want. Can somebody clarify this? Regards, Jie
Re: mod_perl and apache 2.4
I know it doesn't help you, but Debian has been shipping with apache 2.4 and mod_perl working since last year. Of course with Debian, they compile it and stuff it into a package, so we avoid compilation problems. On Thu, Apr 16, 2015 at 10:27 AM, Kevin A. McGrail kmcgr...@pccc.com wrote: On 4/16/2015 10:22 AM, GLG wrote: Unless I am mistaken, it would appear that there is currently no solution as far as running Perl with Apache 2.4 via mod_perl 2.0.8 (or is there a version 2.0.9 out?). That is currently the case. I believe there is an SVN version that will build and work but unless you have a driving need for a feature in 2.4, 2.2 is your better bet right now. Though I noticed last week CentOS 7 shipped with 2.4 and no mod_perl so hopefully we can get that mod_perl 2.4 compatible release soon and they'll retrofit it for 2.4 for those users who rely on package distros. Regards, KAM
Re: Disallow path info
Out of curiosity, Are there links that actually point to / myscript.pl/path/info/... ? Because if you are trying to block them, then it sounds like you don't want to link to them either. Would it be possible to find how they are reaching that page and change the links? Another perspective: If you change the links, then if they somehow get there...then they get a broken page On Mon, Mar 23, 2015 at 6:16 PM, Phillip Hellewell ssh...@gmail.com wrote: On Mon, Mar 23, 2015 at 3:08 PM, Randolf Richardson rand...@modperl.pl wrote: Can you provide some additional detail about what you're doing? I'm just trying to secure my website, and one problem right now is if someone enters http://mysite.example.com/myscript.pl/path/info , not only does it work (which I don't want), but the page is formatted all wrong because it can't find the css, because my HTML uses a relative path, like this: link rel=stylesheet type=text/css href=css/default.css and because of the path of the URL, the web browser looks here for it: http://mysite.example.com/myscript.pl/path/info/css/default.css instead of here where it's actually at: http://mysite.example.com/css/default.css And worst of all, that really long crazy path also works, and returns HTML from my script, and it is not CSS. This affects some js files that I include from my HTML too. What's scary is the fact that this means the browser tries to interpret the HTML that gets returned as both css and javascript. And yes, I already know I can make this work probably by using absolute paths for (but actually I can't, because in my real use case there is a parent folder in the path that comes before the script, on some servers but not others). But I don't want to do a bunch of workarounds to make it work. I want the user to get a 404. As far as I understand it, with AcceptPathInfo Off in efffect, the /path/info portion should cause a 404 error. Of course, if this doesn't work on your system, one possible work-around would be to Yes, and it does work on my system when using the default cgi handler. It only does not work when I am using ModPerl handler. check that $r-path_info is empty and do the following if it isn't: $r-status(Apache2::Const::HTTP_NOT_FOUND); return Apache2::Const::HTTP_NOT_FOUND; What is $r and where does it come from? I know I can check the PATH_INFO env var from my perl script, but my goal is to *not* have to modify all my .pl scripts to do extra checking. Thanks, Phillip
Re: How Do I change the Document Root Per Request
David,
I am not an expert at this, so I don't have an answer.
But I can suggest a few debugging steps to clear out of the way:
1) Confirm that your document root is showing properly in the error log
Does the error log report /var/html/foo/bar.html is not found, or does it
only show the request? On my local apache instance if I do /blah/foo (non
existant), I get: File does not exist: /home/www/html/blah (which has my
document root in it).
2) Confirm that path exists, Look for a folder structure you can create
that will work
if /var/html/foo/bar.html doesn't exist, is it looking for
/var/www/foo/bar.html or /foo/bar.html
3) Do you have any rewrite urls or other location / directory directives
that could be overriding hits?
Check your config files, and then put in some print STDERR / smart comments
to confirm if your routing program is returning the DECLINED
4) Does it work for DirectoryIndexes?
Lathan
On Wed, Mar 11, 2015 at 12:59 PM, David E. Wheeler da...@justatheory.com
wrote:
On Mar 6, 2015, at 5:29 PM, David E. Wheeler da...@justatheory.com
wrote:
And now it works just how I want.
I take it back. It works for files in the root, but not subdirectories.
So say my document root is /var/html, and a request comes in for
/foo/bar.html. Apache has mapped it to /var/html/foo/bar.html, but in my
PerlTypeHandler, I re-map it to /var/html/david/foo/bar.html and set finfo:
sub handler {
my $r = shift;
# We only want to do this once per request.
return DECLINED unless $r-is_initial_req;
# Get the username.
my $user = $r-user or return HTTP_UNAUTHORIZED;
# Return forbidden if the subscriber ID subdirectory does not exist.
my $doc_root = $r-document_root;
my $sub_root = File::Spec-catdir($doc_root, $user);
return HTTP_FORBIDDEN unless -d $sub_root;
# Set the filename.
my $file = File::Spec-catfile($sub_root, substr $r-uri, 1);
$r-filename($file);
$r-finfo(APR::Finfo::stat($file, APR::Const::FINFO_NORM, $r-pool));
return DECLINED;
}
I have no PerlReponseHandler, so Apache handles the response…and returns
404. Note that a request for /hi.txt; it’s only a request in a
subdirectory, /foo/bar.html, that fails. Why? Why isn’t Apache able to find
that file? Is there some other attribute of $r I need to set or unset?
Thanks,
David
Re: How Do I change the Document Root Per Request
On Wed, Mar 11, 2015 at 1:25 PM, David E. Wheeler da...@justatheory.com wrote: On Mar 11, 2015, at 9:59 AM, David E. Wheeler da...@justatheory.com wrote: # Set the filename. my $file = File::Spec-catfile($sub_root, substr $r-uri, 1); $r-filename($file); $r-finfo(APR::Finfo::stat($file, APR::Const::FINFO_NORM, $r-pool)); return DECLINED; } I have no PerlReponseHandler, so Apache handles the response…and returns 404. Note that a request for /hi.txt; it’s only a request in a subdirectory, /foo/bar.html, that fails. Why? Why isn’t Apache able to find that file? Is there some other attribute of $r I need to set or unset? Turns out I was able to fix this issue by unsetting path_info. I just added $r-path_info(undef); To the above code, and now Apache can find the file. I do not understand the relationship between filename (which is often not the full path to a file) and path_info. Fortunately, it looks like I don’t have to. But we might want to consider updating the docs to recommend unsetting path_info when setting the full path to a file in filename. That is very curious. What was in path_info before? Is this a difference between undef and ? Because path_info shouldn't be involved in finding the file, unless Apache is configured to ignore path info. And even that doesn't make sense because you weren't testing with /foo/bar.html/extra/pathinfo You could also check how this directive affects the problem (whether it should be turned off, or if your handler needs accept / deny the path info as with the 'default' argument: AcceptPathInfo On I found this on apache 2.4's docs: http://httpd.apache.org/docs/current/mod/core.html#AcceptPathInfo Best, David
Re: mod_perl for Apache 2.4
On Tue, Jan 13, 2015 at 1:02 PM, Steve Hay steve.m@googlemail.com wrote: We hope to make a release (2.0.9) very soon. Apologies for the delay in its arrival. Great News! Will there be some updated doc pages with that release? I know I'm having troubles with authentication combined with DirectoryIndex, and the less documentation has affected that. Until then you can fetch the latest source, which is likely very close to what will become 2.0.9, from SVN: https://svn.apache.org/repos/asf/perl/modperl/trunk/ On 13 January 2015 at 17:52, Hong Ye h...@cornell.edu wrote: Hi, Does anyone know when mod_perl for Apache 2.4 will be available for download? Where can I download the mod_perl source code that supports Apache 2.4? Thanks, Hong Keep up the good work
Re: Information on using Apache2::AuthCookie with httpd 2.4
On Tue, Oct 21, 2014 at 2:37 AM, Scott Alexander scott.alexan...@humak.fi wrote: Hi, I'm moving from Centos 6 to Centos 7, httpd is 2.4.6 Trying to get Apache2::AuthCookie to work with my module for authentication. Hello Scott, You are not alone. with 2.4, you have to relearn all the quirks in the configuration from when you first started using mod perl v2. I've seen one message about useful information in the debian file /usr/share/doc/libapache2-authcookie-perl/*README.apache-2.4* Does anyone have that? Any other pointers would be greatly appreciated. Did you install it via a package manager or download source from the AuthCookie github? You can find that file here: https://github.com/mschout/apache-authcookie/tree/httpd24 I'm getting in my error log file No authentication done but request not allowed without authentication for loginscript Authentication not configured? Yah, the configuration is quite tricky. Basically, this error is saying that the authentication is required, but the handlers didn't run properly, or weren't configured properly . Here is an example that I have: PerlAddAuthzProvider user Apache2::AuthCookie24-authz_handler Location /perl-status PerlAuthenHandler Apache2::AuthCookie24-authenticate AuthName LDAPLogin AuthType Apache2::AuthCookie24 require group admins set perl handler /Location Terveisin/Regards *Scott Alexander* Järjestelmäasiantuntija Systems Specialist HUMAK Humanistinen ammattikorkeakoulu University of Applied Sciences www.humak.fi Tel. +358 (0)50 411 9556 scott.alexan...@humak.fi
Re: Perl Authorization handler called before authentication handler
On Fri, Sep 12, 2014 at 02:25:49PM -0400, Lathan Bidwell wrote: The documentation for the AuthType field does not seem to give examples for custom auth handlers. The AuthType I put in is the package name that has the auth subroutines in it. This is pulled from other examples, including Apache2::AuthCookie where they set it to their module name. None of the options listed there seem applicable to me: listed where? in Apache2::AuthCookie? I'm not following but never mind. I'm not using basic auth, I'm not using mod_auth_digest, or mod_auth_form, and I don't have no auth... so it doesn't seem right to use AuthType None. I'm not suggesting you do and the config snippet I pasted from the originally referenced URL didn't either. (That AuthType setting was working fine in Apache 2.2) ... but it's all changed in 2.4 ? Yes, The config posted is what we've tried to upgrade our previous config to But I'm going to butt out of this converstaion because (a) I'm just coming to grips with it all myself I still welcome your viewpoint (b) I can't cope with top-posting and the conversation getting all mixed up. My apologies for the top-posting, my mail client makes it a little difficult to respond inline Kind regards Lesley Thank you for your help, Lathan
Perl Authorization handler called before authentication handler
I have looked all around apache's documentation on how to upgrade from 2.2
to 2.4, but they don't include much about using PerlAddAuthzProvider or
PerlAuthenHandler.
I have this config section:
PerlAddAuthzProvider membersuser Application::User::Members-authorize24
DirectoryMatch ^.*/members/
DirectoryIndex disabled
PerlAuthenHandler Application::User::Members-authenticate24
#PerlAuthenHandler Application::User::Members::authenticate24
AuthTypeApplication::User::Members
AuthNameMembers
Require membersuser testing123
/DirectoryMatch
But for some reason, my authorize24 subroutine is being called before my
authenticate24 subroutine.
I have simplified those 2 subroutines down to printing debugging info to
the error log, (the authen sub sets $r-user('testing')), but I cannot
figure out why the handlers are called in the wrong order.
Lathan
Re: Perl Authorization handler called before authentication handler
1) I am sure that the subroutine is called, because I have warn statements
in each subroutine. I can see in the log that authorization24 is called
before authentication24.
2) The url I've been testing is /services/jacl/members/hi.html
@DirectoryMatch: hm, I suppose it might be slightly faster, but I think its
probably better to make it more obvious as to what the config is doing.
This module is used to be able to set up members / subscription areas
fairly dynamically on the site.
On Fri, Sep 12, 2014 at 12:42 PM, André Warnier a...@ice-sa.com wrote:
Lathan Bidwell wrote:
I have looked all around apache's documentation on how to upgrade from 2.2
to 2.4, but they don't include much about using PerlAddAuthzProvider or
PerlAuthenHandler.
I have this config section:
PerlAddAuthzProvider membersuser Application::User::Members-authorize24
DirectoryMatch ^.*/members/
DirectoryIndex disabled
PerlAuthenHandler Application::User::Members-
authenticate24
#PerlAuthenHandler Application::User::Members::
authenticate24
AuthTypeApplication::User::Members
AuthNameMembers
Require membersuser testing123
/DirectoryMatch
But for some reason, my authorize24 subroutine is being called before my
authenticate24 subroutine.
I have simplified those 2 subroutines down to printing debugging info to
the error log, (the authen sub sets $r-user('testing')), but I cannot
figure out why the handlers are called in the wrong order.
Not a solution, just a couple of questions, to make sure that we are
seeing the issue correctly :
1) /is/ the authenticate24 subroutine ever called ? Can you see that ?
2) what is the exact request URL used, when you encounter this issue ?
And then a tentative suggestion :
DirectoryMatch ^.*/members/
can be probably be replaced with the equivalent
DirectoryMatch /members/
which should be a little bit more efficient.
--
BEGIN-ANTISPAM-VOTING-LINKS
--
Teach CanIt if this mail (ID 0aMOgHFdt) is spam:
Spam:http://www.andrews.edu/spam/b.php?i=0aMOgHFdtm=
7dc0ed3625f6c=s
Not spam:http://www.andrews.edu/spam/b.php?i=0aMOgHFdtm=
7dc0ed3625f6c=n
Forget vote: http://www.andrews.edu/spam/b.php?i=0aMOgHFdtm=
7dc0ed3625f6c=f
--
END-ANTISPAM-VOTING-LINKS
Re: Perl Authorization handler called before authentication handler
The documentation for the AuthType field does not seem to give examples for
custom auth handlers.
The AuthType I put in is the package name that has the auth subroutines in
it.
This is pulled from other examples, including Apache2::AuthCookie where
they set it to their module name.
None of the options listed there seem applicable to me:
I'm not using basic auth, I'm not using mod_auth_digest, or mod_auth_form,
and I don't have no auth... so it doesn't seem right to use AuthType None.
(That AuthType setting was working fine in Apache 2.2)
On Fri, Sep 12, 2014 at 1:22 PM, lesleyb lesl...@herlug.org.uk wrote:
On Fri, Sep 12, 2014 at 12:14:35PM -0400, Lathan Bidwell wrote:
I have looked all around apache's documentation on how to upgrade from
2.2
to 2.4, but they don't include much about using PerlAddAuthzProvider or
PerlAuthenHandler.
I have this config section:
PerlAddAuthzProvider membersuser Application::User::Members-authorize24
DirectoryMatch ^.*/members/
DirectoryIndex disabled
PerlAuthenHandler
Application::User::Members-authenticate24
#PerlAuthenHandler
Application::User::Members::authenticate24
AuthTypeApplication::User::Members
AuthNameMembers
Require membersuser testing123
/DirectoryMatch
But for some reason, my authorize24 subroutine is being called before my
authenticate24 subroutine.
I have simplified those 2 subroutines down to printing debugging info to
the error log, (the authen sub sets $r-user('testing')), but I cannot
figure out why the handlers are called in the wrong order.
Summary: Hazarding a complete guess : Wrong syntax?
AuthType
This directive selects the type of user authentication for a directory.
The
authentication types available are None, Basic (implemented by
mod_auth_basic),
Digest (implemented by mod_auth_digest), and Form (implemented by
mod_auth_form). [1]
Not totally familiar with this (just learning it myself) but that gives me
AuthType Basic|Digest|Form|None
Application::Users::Members isn't mentioned in the apache documentation ;-
[2] gives better clues thusly:
Here is the whole configuration section that requires users to
authenticate
before they are allowed to run the registry scripts from /perl/:
Location /perl/
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlAuthenHandler MyApache2::SecretLengthAuth
Options +ExecCGI
AuthType Basic
AuthName The Gate
Require valid-user
/Location
I'm sure you can extrapolate the information in that article and
particularly
that config snippet given above to your particular situation.
Please note that article's use of the Require Directive more on which can
be
found in [3]
Good luck and kind regards
L.
[1] http://httpd.apache.org/docs/current/mod/mod_authn_core.html
[2]
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthzHandler
[3] http://httpd.apache.org/docs/current/mod/mod_authz_core.html
--
BEGIN-ANTISPAM-VOTING-LINKS
--
Teach CanIt if this mail (ID 0aMOhnkWA) is spam:
Spam:
http://www.andrews.edu/spam/b.php?i=0aMOhnkWAm=d801d7a101c2c=s
Not spam:
http://www.andrews.edu/spam/b.php?i=0aMOhnkWAm=d801d7a101c2c=n
Forget vote:
http://www.andrews.edu/spam/b.php?i=0aMOhnkWAm=d801d7a101c2c=f
--
END-ANTISPAM-VOTING-LINKS
