Julian Foad wrote:
> I am not thinking of extending mod_dav_svn, but rather of extending the
> Subversion-internal side of this interaction. Extending the idea of
> Subversion's question (step 1) to include "at revision R" and extending
> if necessary the way Subversion handles its three different actions
> (step 4). Then implementing the "obliterated node-revs" database and the
> obliteration-authz look-up function centrally within Subversion. Like
> this:
>
>
> 1. Subversion wants to know if it can read or write something;
>
> 2. mod_dav_svn (or other plug-in authz module) is asked (by
> Subversion or by Apache, doesn't matter here) about path P
> for user U;
>
> 3. mod_dav_svn (or other) consults its authz rules or database
> and replies "writable" or "read-only" or "no access";
>
> + 4. Subversion asks its "obliterated path-revs database" whether
> path P at rev R is accessible; if not, then change the authz
> result to "no access";
>
> 5. Subversion takes one of three different actions depending on
> whether the "authz result" is "writable" or "read-only" or
> "no access".
>
> The set up and administration of the "obliterated path-revs database"
> used in step 4 can be completely new, not tied to mod_authz_svn or to
> any optional component, and can have whatever administrative interface
> we want.
If you go this route, you'll be happy to learn that our path-based
authorization subsystem already passes around FS roots and paths, so you get
the 'rev R' bit for free.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2404223
Received on 2009-10-06 19:37:02 CEST