httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Auth - how much legacy to preserve ?
Date Wed, 10 Jul 2002 21:11:05 GMT
Dirk, since you're working on a patch for Auth, would it be possible to have
the groups list somewhere in the request structure? It would be great with
web applications, where we can match groups with roles (therefore allowing
authentication to be processed by apache entirely)...

    Pier <> wrote:

> While doing this patch (and ending up with 3 very small modules); I found
> the following legacy behaviour. Any feels as to if we shall kill these
> surprizing behaviourisms in 2.0 or stay as close to 1.3 as possibe ?:
> ->    if there are no requires - but there is Auth happening
> we actively OK.
> ->     If there are no requires for the method (but there are
> requires for that directory for other methods)
> we actively OK.
> ->    If we have for example a (Group,..)File but opening it failes
> then we ignore any 'require group' and DECLINE to other modules.
> Proposal to fixing these leaks (comment now or wait for code) and allowing
> small footprint modules to take part of the process over:
> ->    mod_auth_file
> auth UserID/passwd against file
> DECLINE if no file configured
> ERROR    if file read error (was DECLINE/UNAUTH)
> OK    if ok
> DECLINE if UID not found & non-authoritative
> UNAUTH    otherwise
> ->    mod_auth_groupfile
> checks UserID against required 'require (valid-)group'
> DECLINE if no requirements at all (was OK)
> DECLINE if no group file configurued
> ERROR   if file read error (was IGNORE)
> OK    if in a group
> DECLINE    if no applicable method requirments (was OK)
> DECLINE if no recognized method requirements
> DECLINE if not authoritative and not in recognized groups.
> UNAUTH otherwsie
> ->    mod_require_user
> checks UserID against required 'require (valid-)user'
> DECLINE if no requirements at all (was OK)
> OK if in the list /valid user
> DECLINE if no applicable method requirements. (was OK)
> DECLINE if no recognized requirements
> DECLINE if there are lists, not in list but non
> authoritative
> UNAUTH   otherwise
> And then - to get closer to the old apache:
> ->    mod_auth_default
> auth     DECLINE    if no Basic Auth header/r->user.
> DECLINE if not authoritative
> UNAUTH     otherwise
> check    DECLINE    if no r->user
> OK     if no requires (*)
> OK     if no applicable method requirements (*)
> DECLINE    if not authoriative
> UNAUTH    otherwise
> *: I.e. in mod_auth_default we 'fix' to get closer to the behaviour from
> 1.3;  An alternative would be to not do this and change to always UNAUTH
> then when there is r->user information provided and not authoritative.
> I do want to allow fall through - so that a perl/php/java backend is able
> to get access if/when needed. Thus:
> ->    apache core
> auth    OK
> check    OK
> Of course - the mod_auth_default could also be in the core of the http
> proocol handling.
> Does this make sense ?
> Dw.

[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]

View raw message