httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject authentication rewrite
Date Tue, 27 Aug 2002 04:18:16 GMT
I need to be able to get at the authentication backends to implement
some DAV enhancements - namely DAV has its own authentication model
(DAV ACL support).  My idea would be to allow mod_dav to reuse the
aaa backends and just implement the client-facing bits there.

Therefore, I've begun to split up the authentication frontends
and backends.  I've used the DAV philosophy by having providers
and registering them.

At this point, I have "file" and "dbm" backends which mod_auth_basic
and mod_auth_digest use.  Hopefully, it should be trivial to add a
"ldap" backend.  (mod_auth_basic is essentially mod_auth.)

As it is quite large (diffs are useless), you can find the code here:

It should be a drop-in replacement to the modules/aaa dir.  I've
got it handling Basic auth requests with both file and dbm backends.
I've yet to compile digest, but I should have changed the appropriate
bits to get it to cooperate.  mod_auth_{dbm|file}.c does nothing
except provide the correct auth_provider structure so that the
authentication front-ends can use them.

Key files:
mod_auth.h 	  - Header file
auth_provider.c   - Similar to mod_dav's registration of providers
mod_auth_basic.c  - Implementation of basic auth  (rewritten)
mod_auth_digest.c - Implementation of digest auth
mod_auth_dbm.c    - DBM provider
mod_auth_file.c   - File provider

For a file-backed authentication, use:

AuthProvider file
AuthUserFile conf/dot-user
AuthType Basic
AuthName "Test Users"

For a DBM-backed authentication, use:

AuthProvider dbm
AuthDBMType default 
AuthUserFile conf/dot-user-dbm dbm
AuthType Basic
AuthName "Test Users"

(Why AuthUserFile is a Take2 in mod_auth_dbm is unclear.  That is
how it was before.)

I'd like to get this in the tree as I can't really start on the DAV
ACL stuff until aaa is properly split.

Yes, I realize this breaks configs, but this is the 'right' model to
move towards (and has been discussed here before, but no one has
sat down and implemented it).  This has the large advantage of
getting rid of a lot of duplicate code.  Hopefully, we could throw
out the code in server/protocol.c that deals with authentication!

Comments?  Thoughts?  -- justin

View raw message