>>> On 1/6/2006 at 1:15:33 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> >> 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
