httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Davies" <bdav...@stickyeyes.com>
Subject RE: Dynamicly insert 'require' into request
Date Wed, 22 Jul 2009 15:32:22 GMT
First of all, thank you to everyone who has replied. Every reply has been
enlightening and helpful. I'm clearly a novice to module development, and I
only ever post when I am truly stuck and need help, and only when I have
exhausted all possible avenues (I own all of the books mentioned regularly
on this list and each has a pretty broken spine and is scribbled with notes
:)

I'm not a novice programmer, but am a novice to C. And C is a very
intimidating language when you've only programmed in 'safer' languages for
15 years :) On top of that, the documentation for the Apache API and APR
stuff really consists of an API listing and not much else. Nicks book is
pretty much the only documentation I've read that was actually any help.

Saying that, I have personally learnt more from this mailing list than most,
so please consider my multiple postings a compliment. Saying that, I will
reduce my postings in future to a few succinct questions. 

Cheers!

Ben Davies

-----Original Message-----
From: Ray Morris [mailto:support@bettercgi.com] 
Sent: 22 July 2009 14:36
To: modules-dev@httpd.apache.org
Subject: Re: Dynamicly insert 'require' into request

> 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 
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 
to send two different headers with the 401, their 
hooks have to run BEFORE the 401 is sent to the 
client.  I would definitely test that if I were the 
OP, because I think you're making way more work for 
yourself than you need to.  I think you can simply 
return OK from check_user_id for publicly accessible
resources.  

   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 
to be able to get help when needed.  This series 
of questions has gone on a bit longer than most on 
this list.  Soon, I'm sure, knowledeable people on 
the list will get tired of answering and think to 
themselves "you can either read the book and look 
at other modules to learn how to write this yourself, 
or you can hire me to write it for you.  I'm not 
going to write your module for you on the list, by 
answering dozens of questions that are all clearly 
answered in chapter 7 of the book."  I'm guessing 
you probably have one or two questions left before
people get tired of answering - use them wisely, 
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.
> 
> 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.
> 
> 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 :)
> 
> 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.
> 
> If the resource IS publicly available, I need to somehow remove the
> require
> directive from the request, and then return OK from the access() 
> 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.
> 
> >From what I can make out, this is how Apache would handle the
> process.
> 
> No to see if I can actually modify the request->requires array, and 
> 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.
> 
> Fun fun fun!
> 
> 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?
> 
> Cheers!
> 
> Ben
> 
> 
> -----Original Message-----
> From: Tom Evans [mailto:tevans.uk@googlemail.com] 
> Sent: 22 July 2009 12:24
> To: modules-dev@httpd.apache.org
> Subject: RE: Dynamicly insert 'require' into request
> 
> 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().
> > 
> > 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.
> > 
> > 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?
> > 
> > Cheers,
> > 
> > Ben
> > 
> 
> 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.
> 
> There may be a better way :)
> 
> Cheers
> 
> Tom
> 
> 



Mime
View raw message