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
[EMAIL PROTECTED]
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
