Re: wildcard authz docs question

Daniel:

On Mon, Apr 17, 2017 at 21:13 Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:

> Stefan Fuhrmann wrote on Mon, Apr 17, 2017 at 22:22:33 +0200:
> > On 15.03.2017 10:55, Daniel Shahaf wrote:
> > >>From the 1.10 draft release notes:
> > >
> > >>All wildcards apply to full path segments only, i.e. * never matches
> > >>/, except for the case where /**/ matches zero or more path segments.
> > >>For example, /*/**/* will match any path which contains at least
> > >>2 segments and is equivalent to /**/*/* as well as /*/*/**.
> > >Are «/*/**/*» «/**/*/*» «/*/*/**» really equivalent? I would have
> > >expected the first two to match any node except / and /'s immediate
> > >children, but I wouldn't expect the third form to match /trunk/iota
> > >where iota is a file, since the pattern has a trailing slash after the
> > >non-optional second component.
> > How do you know that /trunk/iota is a file?
>
> I was reviewing the API docs as a black box, i.e., from a user
> (repository admin) perspective, not from an implementation perspective.
>
> From that perspective, I would say that having a [/trunk/iota/**]
> stanza to apply to a /trunk/iota file violates the principle of least
> surprise.

From a very critical point of view I agree.

However, the point of wildcards is to easily reserve a complete namespace.
If we do not apply that stanza apply to the file means requiring 2 stanzas
to cover the space entirely. That's both expensive and brittle (2X stanzas
and requires remembering to treat them in pairs - both when adding and when
removing).

And I think the "surprise" will be very short-lived if at all.

From a cost/benefit standpoint I think it is extremely positive.

Doug

>
> > The problem is that the authz callback does not provide
> > enough context information to make that distinction.
> > We might extend the interface in the future - allowing
> > to restrict rules to exclusively match files or dirs only.
>
> Are you referring to svn_repos_authz_check_access()? [which doesn't
> have an svn_fs_t handle or the information to open one]
>
> > But making that backward compatible adds quite a bit
> > of complexity that I don't want to pile on there in 1.10.
>
> I don't understand this sentence at all. Why do we need to be backwards
> compatible (this is a new feature), and why is being back compat in
> this case necessarily expensive?
>
> Moreover, implementation considerations aside, there is still the
> question of what the documentation should say about this situation.
>
> Cheers,
>
> Daniel
>

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER
T +1 925 396 1125
*E* doug.robinson_at_wandisco.com
-- 
World Leader in Active Data Replication™
*Find out more wandisco.com <http://wandisco.com/>*
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE 
PRIVILEGED
If this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.