"C. Michael Pilato" <cmpilato_at_collab.net> writes:
> Martin tells me that bzr-svn was banking on this ability to request
> all revision logs from any location, because reparenting to the root
> URL and fetching logs from there might not be permissible due to
> access restrictions. So, if we assume a scenario where I'm allowed to
> read /trunk but not /, presumably bzr-svn would use /trunk for the
> session URL (which is allowed), but then ask for logs on /. Because
> we only validate the returned logs, this would work fine -- we'd just
> wind up return incomplete metadata for any revisions that contained
> changed to paths outside of /trunk. As a general statement about the
> usability of Subversion in auth-restricted scenarios, this kinda makes
> sense. (We've seen other situations where, say, I can't do a move of
> /trunk/foo to /trunk/bar because we try to anchor the commit editor at
> /. Those kinds of things are easy to explain to a Subversion
> developer, but users are left bewildered.)
>
> So, what to do? Do we explicitly allow absolute paths through all of
> our RA interfaces? (Please don't make inconsistent policy here and
> give per-method exceptions.) Do we stick with the published APIs and
> send our best wishes and a vase of flowers to folks who were
> previously misusing the APIs and have now been caught doing so?
Why should access restrictions prevent someone from merely anchoring an
RA session at a particular URL, and then running log requests based from
that anchor? The access controls should, of course, limit what
responses come back from the request, but I don't see why they should
prevent what Martin assumes "might not be permissible".
If there is a bug here, perhaps it's in the way the server enforces
access restrictions?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-03 20:12:28 CEST