Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <43BE8217.6720.00AC.0@novell.com>
Date: Fri, 06 Jan 2006 14:46:11 -0700
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@httpd.apache.org>,<joshua@slive.ca>
Subject: Authorization and Access Control 2.3 vs. 2.2 (was Re: svn
	commit: r360207 -  in /httpd/httpd/branches/authz-dev...)
References: <20051231002849.31514.qmail@minotaur.apache.org>
  <e498c1660601011428p53939285xf42a4573146a3865@mail.gmail.com>
 <e498c1660601061215x24fdd3c6g29d38f4ccd487fe@mail.gmail.com>
In-Reply-To: <e498c1660601061215x24fdd3c6g29d38f4ccd487fe@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


>>> On 1/6/2006 at 1:15:33 pm, in message
<e498c1660601061215x24fdd3c6g29d38f4ccd487fe@mail.gmail.com>,
joshua@slive.ca 
wrote:
> [Looks like this didn't go through the first time.  Do we still have
> active moderation on this list?]
> 
> ---------- Forwarded message ----------
> From: Joshua Slive <joshua@slive.ca>
>> New Revision: 360207
>>
>> URL: http://svn.apache.org/viewcvs?rev=360207&view=rev 
>> Log:
>> Remove the 'satisfy' directive and the ap_satisfy() and
ap_requires() APIs 
> since they no longer serve a purpose
> 
> You probably already have thought of this, but I'll point out the
> obvious anyway.
> 
> These changes are much more invasive in terms of upgrade-path than
> anything in the 1.3 to 2.0 change.  In particular, they will break
> almost all .htaccess files, which the earlier changes did not.  This
> will make it almost impossible for many people to upgrade.
> 
> Has there been any thought to keeping the old directives in a
> compatibility module or something like that?
> 
> Joshua.

You are right these changes do break backwards compatibility rather
severely in the area of authorization and access control.  But the point
of all of this is to pull together two forms of authorization and
reimplement them as a single point.  This requires that something needs
to go.  Trying to maintain backward compatibility in this case would
create a nightmare of confusion especially if somebody tried to mix the
old way (ie. Order, Allow, Deny, Satisfy) with the new way (Require,
Reject).  In fact the only real reason for the 'Satisfy' directive was
an attempt to tie together in some way the host based access control
with authentication/authorization.  This refactoring pulls both of these
areas together which eliminates the need for the 'Satisfy' directive. 
In addition to adding requested functionality to authorization.

Although we had some discussion about this at ApacheCon, I was hoping
to generate more of a discussion on-list with my initial proposal. 
Since that didn't really happen, I am hoping that now that there is an
actual implementation that is ready to be dumped back into Trunk, it
might be easier to understand and discuss the implications.  I will be
posting another message soon that lays out what the effects are with
regards to functionality, backwards compatibility and benefits.  At
about the same time, I would like to merge all of the changes in
/branch/authz-dev back into trunk.  

Brad