Dan Poirier wrote:
I'd find it much easier to understand if we had fewer directives, and
just built up the more complicated ideas by writing boolean expressions,
which most of us already know how to cope with.
Perhaps, and the underlying code should support a range of alternative
configuration schemes; if someone wants to add an expression parser,
that should be feasible.
My own perspective was that I wanted to satisfy number of goals,
in descending order of priority:
First, and most important, I wanted to ensure default 2.2-style
authz. Imagine administrating a large mass virtual hosting service
whose customers have uploaded thousands of .htaccess files, and trying
to upgrade to 2.4. Clearly, those .htaccess files need to work exactly
as before. Even if we supplied a batch conversion script that could
find and auto-upgrade them, customers would later upload their own private
copies of their old files, thus inadvertently breaking their sites.
So, that meant an OR-like context for Require directives, and
no merging of authz configurations by default. This whole thread
started because I was trying mod_authz_dbd and noticed it didn't
work as expected because AuthzMergeRules was On (i.e., "OR") by default.
(In my previous message I described switching to an AND-like default
context for Require directives, but realized before committing that
that would break with this prime directive of backwards-compatibility.)
So, if people could please test with 2.2-style authz configurations
and make sure everything works as expected, that would be superb.
Second, I wanted to simplify things a little. The revised
mod_auth.h and mod_authz_core.c have shrunk a little, and I felt I
could remove the default authn/z modules. (Having both core and
default modules for authn and authz, any of which could be compiled
out, seemed a likely source of trouble.)
Third, while looking into how mod_authz_core worked, I found
some ways to configure it that would cause unexpected results,
and while trying to fix those came to the conclusion I needed to
start over with a tree-based implementation.
Doing that and working through the implications of a non-Boolean
tri-state logic (where negating a false value results in a neutral,
not true, value) I found that adding negated authz container directives
was something that just fell out naturally.
Finally there was a certain amount of bike-shed re-painting in
the form of renaming configuration directives. I settled on
Match, <MatchAll>, etc. based on Eric Covener's comments.
If people dislike those names, please jump in and change them.
Or if most folks think we'd be better off without authz containers
entirely, please vote for the following patch, which simply turns all
that stuff off, leaving (I hope) a fairly clean core authz implementation
that supports default 2.2-style behaviour and is extensible down the road,
should that be desired.
Chris.
Index: mod_authz_core.c
===================================================================
--- mod_authz_core.c (revision 710120)
+++ mod_authz_core.c (working copy)
@@ -405,6 +405,7 @@
return NULL;
}
+#ifdef AUTHZ_CORE_CONTAINERS
static const char *add_authz_section(cmd_parms *cmd, void *mconfig,
const char *args)
{
@@ -534,6 +535,7 @@
return NULL;
}
+#endif /* AUTHZ_CORE_CONTAINERS */
static int authz_core_check_section(apr_pool_t *p, server_rec *s,
authz_section_conf *section, int is_conf)
@@ -634,6 +636,7 @@
"specifies legacy authorization directives "
"of which one must pass "
"for a request to suceeed"),
+#ifdef AUTHZ_CORE_CONTAINERS
AP_INIT_RAW_ARGS("Match", add_authz_provider, NULL, OR_AUTHCFG,
"specifies authorization directives that must pass "
"(or not) for a request to suceeed"),
@@ -656,6 +659,7 @@
"controls how a <Directory>, <Location>, or similar "
"directive's authorization directives are combined with "
"those of its predecessor"),
+#endif /* AUTHZ_CORE_CONTAINERS */
{NULL}
};
