Re: Perl Authorization handler called before authentication handler
* Lathan Bidwell wrote:
> Date: Fri, 12 Sep 2014 12:14:35 -0400
> From: Lathan Bidwell
> To: modperl@perl.apache.org
> Subject: Perl Authorization handler called before authentication handler
Not sure if you still need this, but my findings are it is the
correct behaviour under Apache24 for the authz to run first; if anything
in authz requires any info from the authn phase, authn will be
run and authz will be re-run after that.
As authz behaves "drastically" different under ap24 (for the better),
any existing ap2.* modperl authn/authz modules will need to be overhauled.
You can play with the RequireAll/RequireAny containers to get a hang of it.
I am certainly exploring it now myself.
Regards,
Jie
> 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
>
>
> DirectoryIndex disabled
> PerlAuthenHandler Application::User::Members->authenticate24
> #PerlAuthenHandler Application::User::Members::authenticate24
>
> AuthTypeApplication::User::Members
> AuthName"Members"
>
> Require membersuser testing123
>
>
>
> 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
>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
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 ?
But I'm going to butt out of this converstaion because
(a) I'm just coming to grips with it all myself
(b) I can't cope with top-posting and the conversation getting all mixed up.
Kind regards
Lesley
>
> On Fri, Sep 12, 2014 at 1:22 PM, lesleyb 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
> > >
> > >
> > > DirectoryIndex disabled
> > > PerlAuthenHandler
> > Application::User::Members->authenticate24
> > > #PerlAuthenHandler
> > Application::User::Members::authenticate24
> > >
> > > AuthTypeApplication::User::Members
> > > AuthName"Members"
> > >
> > > Require membersuser testing123
> > >
> > >
> > >
> > > 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/:
> >
> >
> > SetHandler perl-script
> > PerlResponseHandler ModPerl::Registry
> > PerlAuthenHandler MyApache2::SecretLengthAuth
> > Options +ExecCGI
> >
> > AuthType Basic
> > AuthName "The Gate"
> > Require valid-user
> >
> > "
> > 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=0aMOhnkWA&m=d801d7a101c2&c=s
> > Not spam:
> > http://www.andrews.edu/spam/b.php?i=0aMOhnkWA&m=d801d7a101c2&c=n
> > Forget vote:
> > http://www.andrews.edu/spam/b.php?i=0aMOhnkWA&m=d801d7a101c2&c=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 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
> >
> >
> > DirectoryIndex disabled
> > PerlAuthenHandler
> Application::User::Members->authenticate24
> > #PerlAuthenHandler
> Application::User::Members::authenticate24
> >
> > AuthTypeApplication::User::Members
> > AuthName"Members"
> >
> > Require membersuser testing123
> >
> >
> >
> > 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/:
>
>
> SetHandler perl-script
> PerlResponseHandler ModPerl::Registry
> PerlAuthenHandler MyApache2::SecretLengthAuth
> Options +ExecCGI
>
> AuthType Basic
> AuthName "The Gate"
> Require valid-user
>
> "
> 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=0aMOhnkWA&m=d801d7a101c2&c=s
> Not spam:
> http://www.andrews.edu/spam/b.php?i=0aMOhnkWA&m=d801d7a101c2&c=n
> Forget vote:
> http://www.andrews.edu/spam/b.php?i=0aMOhnkWA&m=d801d7a101c2&c=f
> --
> END-ANTISPAM-VOTING-LINKS
>
>
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 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
>>
>>
>> DirectoryIndex disabled
>> PerlAuthenHandler Application::User::Members->
>> authenticate24
>> #PerlAuthenHandler Application::User::Members::
>> authenticate24
>>
>> AuthTypeApplication::User::Members
>> AuthName"Members"
>>
>> Require membersuser testing123
>>
>>
>>
>> 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 :
>
>
> can be probably be replaced with the equivalent
>
> 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=0aMOgHFdt&m=
> 7dc0ed3625f6&c=s
> Not spam:http://www.andrews.edu/spam/b.php?i=0aMOgHFdt&m=
> 7dc0ed3625f6&c=n
> Forget vote: http://www.andrews.edu/spam/b.php?i=0aMOgHFdt&m=
> 7dc0ed3625f6&c=f
> --
> END-ANTISPAM-VOTING-LINKS
>
>
Re: Perl Authorization handler called before authentication handler
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
>
>
> DirectoryIndex disabled
> PerlAuthenHandler Application::User::Members->authenticate24
> #PerlAuthenHandler Application::User::Members::authenticate24
>
> AuthTypeApplication::User::Members
> AuthName"Members"
>
> Require membersuser testing123
>
>
>
> 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/:
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlAuthenHandler MyApache2::SecretLengthAuth
Options +ExecCGI
AuthType Basic
AuthName "The Gate"
Require valid-user
"
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
Re: Perl Authorization handler called before authentication handler
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
DirectoryIndex disabled
PerlAuthenHandler Application::User::Members->authenticate24
#PerlAuthenHandler Application::User::Members::authenticate24
AuthTypeApplication::User::Members
AuthName"Members"
Require membersuser testing123
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 :
can be probably be replaced with the equivalent
which should be a little bit more efficient.
