Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of support@bettercgi.com
 designates 216.17.105.202 as permitted sender)
Date: Wed, 22 Jul 2009 08:35:32 -0500
From: Ray Morris <support@bettercgi.com>
Subject: Re: Dynamicly insert 'require' into request
To: modules-dev@httpd.apache.org
In-Reply-To: <009401ca0ac7$dea49c60$9bedd520$@com> (from
	bdavies@stickyeyes.com on Wed Jul 22 07:28:05 2009)
Message-Id: <1248269732.17411.0@raydesk1.bettercgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> Have I made a massive assumption regarding the
> returning of the 403 header before check_user(),
> for example?

   That's exactly what I first thought about when=20
I read your email.  I think the 401 "authorization
required" is sent only AFTER check_user_id() is run.
Remember there's more than one way to authenticate
a client - basic auth and digest auth are two that
come standard.  In order for mod_auth and mod_auth_digest=20
to send two different headers with the 401, their=20
hooks have to run BEFORE the 401 is sent to the=20
client.  I would definitely test that if I were the=20
OP, because I think you're making way more work for=20
yourself than you need to.  I think you can simply=20
return OK from check_user_id for publicly accessible
resources. =20

   Also think carefully about "satisfy any".
"Satisfy any" means it has to pass EITHER a) access
or b) authentication, which may be just what you're
trying to do.

   Lastly, let me mention that I'd like the the OP=20
to be able to get help when needed.  This series=20
of questions has gone on a bit longer than most on=20
this list.  Soon, I'm sure, knowledeable people on=20
the list will get tired of answering and think to=20
themselves "you can either read the book and look=20
at other modules to learn how to write this yourself,=20
or you can hire me to write it for you.  I'm not=20
going to write your module for you on the list, by=20
answering dozens of questions that are all clearly=20
answered in chapter 7 of the book."  I'm guessing=20
you probably have one or two questions left before
people get tired of answering - use them wisely,=20
when you actually need them.
--
Ray Morris
support@bettercgi.com

Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/

Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/

Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php


On 07/22/2009 07:28:05 AM, Ben Davies wrote:
> > One solution would be to set a note for your hook in an earlier
> stage,
> > and then return DECLINED from your handler when you detect that
> note.
>=20
> Ah, but from what I can work out, before the check_user() hook fires,
> the
> 403 is sent to the client because of the presence of the require. I
> can't
> have the check_user() hook return DECLINED because its too late: the
> 403 has
> been sent back automatically.
>=20
> But additionally, I can't return DECLINED from the access() hook
> (which
> fires before the check_user() hook) because if the resource requested
> is
> publicly accessible, then the access() hook should return OK :)
>=20
> So, to me, the only solution is:
> In the access() hook, if the resource is NOT publicly accessible,
> return OK.
> This will make apache recognise the require directive, return a 403,
> and
> then fire the check_user() and auth() hooks.
>=20
> If the resource IS publicly available, I need to somehow remove the
> require
> directive from the request, and then return OK from the access()=20
> hook.
> This
> means that the 403 won't be returns (as there is no require directive
> set
> anymore) which means no authentication (check_user()) hook is fired
> and
> subsequently no authorization (auth()) hook either.
>=20
> >From what I can make out, this is how Apache would handle the
> process.
>=20
> No to see if I can actually modify the request->requires array, and=20
> if
> so,
> if that will affect the request processing after exiting the access()
> hook
> so that the 403 and the check_user() and auth() hooks don't fire.
>=20
> Fun fun fun!
>=20
> Can someone with a deeper knowledge of Apache than me comment if this
> sounds
> like crazy talk? Have I made a massive assumption regarding the
> returning of
> the 403 header before check_user(), for example?
>=20
> Cheers!
>=20
> Ben
>=20
>=20
> -----Original Message-----
> From: Tom Evans [mailto:tevans.uk@googlemail.com]=20
> Sent: 22 July 2009 12:24
> To: modules-dev@httpd.apache.org
> Subject: RE: Dynamicly insert 'require' into request
>=20
> On Wed, 2009-07-22 at 10:43 +0100, Ben Davies wrote:
> > Okay, so upon further inspection, it appears that there may not be
> an
> > equivalent function for mod_perls set_handlers().
> >=20
> > This leads me to a problem: how do I "turn off" a hook, especially,
> as the
> > check_user() hook expects the r->user property to contain the
> username,
> > meaning that the sending of a 403 happens before the check_user()
> hook is
> > called. Whatever it is I need to do, I need to do in the access()
> hook.
> >=20
> > I was hoping it might be something as simple as removing my require
> entry
> > from the require array. Has anyone had any experience with this? If
> so,
> > could you comment on techniques?
> >=20
> > Cheers,
> >=20
> > Ben
> >=20
>=20
> One solution would be to set a note for your hook in an earlier=20
> stage,
> and then return DECLINED from your handler when you detect that note.
>=20
> There may be a better way :)
>=20
> Cheers
>=20
> Tom
>=20
>=20