httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Marmor <mar...@netmask.it>
Subject Proposal: Integration of AAA Providers with User Management
Date Mon, 25 Jul 2005 13:38:50 GMT
Joe Orton wrote:
> 
> On Mon, Jul 25, 2005 at 08:24:39AM -0400, Geoffrey Young wrote:
> > ...
> > it will, of course, be in perl - if people are really just shell'ing out to
> > a binary from a CGI then there's no real reason it _needs_ to be in C.  at
> > least that I can see :)
> 
> The reason the tool should continue to be in C if it's doing database
> manipulation is to ensure that it uses exactly the same database
> libraries that httpd does.  Doing it in Perl can't ensure that (hence
> htdbm to replace dbmmanage).

The following looks to me elegant and clean:

First, go to mod_auth.h, and append new fields to authn_provider
struct; Currently, it contains 2 pointers to provider-supplied functions
to GET data (one is (*check_password)() and the 2nd (*get_realm_hash)()
).
I want something like:
	(*set_password)(request_rec *r, const char *user,
	const char *realm, const char *password);
when realm is optional (can be NULL for non-realm authentications).
(we can add a parameter to specify if this should be set only if the
user doesn't exist, or only if it exists, or in any case, but I prefer
to avoid such a parameter, because check_password can tell us if the
user already exists). Or course, a (*del_user)() function is needed
too.

In the second phase, it will be very easy to add these functions to
the various providers; Most of the work will be copy-paste from
htpasswd/htdigest/htdbm to the appropriate provider.

Now, we have internal API that supports not only GET of data from the
auth storage, but also SET/ADD/DEL of data. So we can continue to the
3rd phase:

In the 3rd phase, we can write functions that will call the appropriate
SET/DEL functions, and attach them to special flags of HTTPD (like "-l"
or other flags that cause HTTPD to do various actions without opening a
real server). apachectl will be modified too, to support the new
functionality of httpd, so management of users, no matter what storage
(file/dbm/database) or algorithm (basic/digest/etc.), will be done by
apachectl.

By the way: if httpd is invoked only for a user management task, there
will not be a request_rec, which is required by the functions; However,
if I recall correctly, the request_rec is needed only for its pool and
for logging errors, which can be done with fake request_rec too, so it
is not a problem.

In the 4th phase, we can call these functions from anywhere in httpd,
and even write a special module to allow management of users, with the
appropriate permissions, of course (so only a special user from a
specific location can manage other users, and everybody can change his
own password, etc.).

Opinions?
-- 
Eli Marmor
marmor@netmask.it
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.:   +972-9-766-1020          8 Yad-Harutzim St.
Fax.:   +972-9-766-1314          P.O.B. 7004
Mobile: +972-50-5237338          Kfar-Saba 44641, Israel

Mime
View raw message