Re: modules + callbacks = ap_get_module_config(r->per_dir_config,var)
Mike wrote:
cation 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.
Thanks for the reply.
The problem is that I need access to this info in the callback
function, and the callback does not have access to the request_rec.
For example..
auth_basic_user(){
do_some_stuff(); //Gets the user name and password(password as you
suggested) and stores them so that they can be used by later
callback. mm_login
call_cclient_to_auth();
return;
}
call_cclient_to_auth() takes no parms and eventually uses callback
functions to do things, one of these being to get the user/password
to auth with. This is by design of the c-client lib and not
something I can change.
PAM is very similar - it uses a callback. However, it also uses a
void pointer that gets passed in a setup function earlier. Anything
like that available? (e.g. to call it with an r-> or a custom
structure with the info?)
Unfortunately not, that was what I had hoped to do originally.
Mike.
Is there a thread-safe form of the library? (that sort of thing will
have functions that take parameters if it uses callbacks). Another
alternative is to set up another "daemon" process for the authentication
mechanism - which may or may not cause the rest of the module to fail
depending on what you do.
In other words, you just might have to use a global variable and set up
mutex's to prevent multiple instances from calling during the
authentication - or else expect the unexpected.
Joe
Re: modules + callbacks = ap_get_module_config(r->per_dir_config,var)
cation 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.
Thanks for the reply.
The problem is that I need access to this info in the callback
function, and the callback does not have access to the request_rec.
For example..
auth_basic_user(){
do_some_stuff(); //Gets the user name and password(password as you
suggested) and stores them so that they can be used by later
callback. mm_login
call_cclient_to_auth();
return;
}
call_cclient_to_auth() takes no parms and eventually uses callback
functions to do things, one of these being to get the user/password
to auth with. This is by design of the c-client lib and not something
I can change.
PAM is very similar - it uses a callback. However, it also uses a
void pointer that gets passed in a setup function earlier. Anything
like that available? (e.g. to call it with an r-> or a custom
structure with the info?)
Unfortunately not, that was what I had hoped to do originally.
Mike.
Re: modules + callbacks = ap_get_module_config(r->per_dir_config,var)
Mike wrote:
Joe Lewis wrote:
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.
Thanks for the reply.
The problem is that I need access to this info in the callback
function, and the callback does not have access to the request_rec.
For example..
auth_basic_user(){
do_some_stuff(); //Gets the user name and password(password as you
suggested) and stores them so that they can be used by later callback.
mm_login
call_cclient_to_auth();
return;
}
call_cclient_to_auth() takes no parms and eventually uses callback
functions to do things, one of these being to get the user/password to
auth with. This is by design of the c-client lib and not something I
can change.
PAM is very similar - it uses a callback. However, it also uses a void
pointer that gets passed in a setup function earlier. Anything like
that available? (e.g. to call it with an r-> or a custom structure with
the info?)
Joe
Re: modules + callbacks = ap_get_module_config(r->per_dir_config,var)
Joe Lewis wrote:
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.
Thanks for the reply.
The problem is that I need access to this info in the callback function,
and the callback does not have access to the request_rec.
For example..
auth_basic_user(){
do_some_stuff(); //Gets the user name and password(password as you
suggested) and stores them so that they can be used by later callback.
mm_login
call_cclient_to_auth();
return;
}
call_cclient_to_auth() takes no parms and eventually uses callback
functions to do things, one of these being to get the user/password to
auth with. This is by design of the c-client lib and not something I can
change.
Thanks.
Re: modules + callbacks = ap_get_module_config(r->per_dir_config,var)
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 : r->user 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. Joe
modules + callbacks
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. Many thanks. Mike.
