httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Lewis <>
Subject Re: modules + callbacks = ap_get_module_config(r->per_dir_config,var)
Date Fri, 26 Jan 2007 15:36:16 GMT
Mike wrote:
> Hi,
> The Subject here may be completely wrong, so I will describe what I am 
> doing. Some years ago I hacked together an authentication module  
> which uses the c-client imap lib. I decided to take a look at porting 
> it to 2.0 only to realize that the code is complete crap,thus I am 
> looking to fix (Disclaimer, I am not a C Programmer).
> C-client is implemented such that it obtains data via callback 
> functions which must be defined by the caller. One of these  functions 
> is to obtain the username and password to auth with. Since this was a 
> callback function I did not have any apache context handy to store 
> things in so I stuffed the user and password in globals. This is 
> obviously bad so I am looking to do it the correct way. My current 
> thought was to create some named shared memory segment in the process 
> pool to store this in and then maybe store the process pool in a 
> global. Reading/writing the user/pass pair to the pool would be 
> controlled by a mutex.
> On second thought though this isn't really that much different than if 
> I controlled access to the current globals with a mutex, there must be 
> a better way? Any advice/pointers appreciated.
Authentication in Apache 2.0 is actually very nicely engineered.  If you 
want to store the username and the password, you can.  However, you 
don't have to.  It is available in the request structure data and by a 
single function :

pass = ap_get_basic_auth_pw(r, (const char **) &p_pass);

You could also put in the data to grab the credentials from the headers, 
if you wanted to use something other than basic_auth.

If you need to store anything, there are two suggested methods :

  1) a module configuration structure (better than globals)
  2) globals (used for static globals, I'd still suggest use of the 
module config structure)
  3) shared memory

Each has their benefits.  In my opinion, if you can get away with using 
a module configuration structure, it is the best option - it doesn't 
matter if you are using the thread- or -prefork- MPM's, and it is simple 
to use.


View raw message