The following reply was made to PR apache-api/2024; it has been noted by GNATS.
From: Jay Soffian <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
Apache bugs database <[EMAIL PROTECTED]>, Marc Slemko <[EMAIL
PROTECTED]>
Cc: Subject: Re: apache-api/2024: adding auth_why to conn_rec
Date: Wed, 01 Apr 1998 11:19:26 -0500
+--Marc Slemko <[EMAIL PROTECTED]> once said:
|
|On 1 Apr 1998 [EMAIL PROTECTED] wrote:
|
|> Just what would AUTH_WHY contain though? The reasons for access
|> being permitted are essentially arbitrary...
|
|I'm not sure I like the idea either. It starts going a bit crazy when you
|look at what modules can actually do for auth...
|
|What could be useful is a group field to complement the user field.
|Users and groups are a reasonably generic concept in many auth modules, so
|setting the group they were found in could be useful and is something that
|people do ask for a lot.
I agree, reasons for access being permitted are arbitrary, but all
auth modules (at least with all modules I have looked at) act on a
'require ...'. It is my suggestion then that it is up to the module to
decide what AUTH_WHY is set to. For the mod_auth files that handle
'require user ...', 'require group ...', and 'require valid-user', the
suggested behavior is that they set AUTH_WHY to 'user ...', 'group
...', or 'valid-user', where in the case of 'user ...', '...' is the
username that matched, and in the case of 'group ...', '...' is the
group the user is a member of that matched.
For auth_modules that grant access based on other criteria (for
example, we are using a mod_auth_sys that we modified to work with NIS
and accecpt 'require netgroup ...'), it is entirely up to module
author to determine what 'AUTH_WHY' should be set to. As long as their
behavior is documented, users of 'AUTH_WHY' shouldn't have any trouble
knowing what to do.
I would argue that is it even valid for an auth_ module not to set
AUTH_WHY at all, and that a user of AUTH_WHY should treat this
condition as 'the reason for access is unknown', and act accordingly.
j.
--
Jay Soffian <[EMAIL PROTECTED]> UNIX Systems
Administrator
Cox Interactive Media
