Re: Subversion AuthZ Wildcards

Brane:

On Thu, Jun 1, 2017 at 7:36 PM, Branko Čibej <brane_at_apache.org> wrote:

> On 02.06.2017 00:11, Doug Robinson wrote:
> >> * /trunk now uses are specialized parser for authz.
> >> Some accidental features of the previously used
> >> config parser are no longer available. In particular,
> >> sections may no longer be repeated and there is
> >> no support for value expansion.
> >>
> > Just checking: can there be 2 sections of:
> >
> > [/]
> > * = r
> >
> > [/]
> > accountA = rw
> > accountB = rw
> >
> > Or is this now going to fail?
>
> This is now going to fail. People would have to write:
>
> [/]
> * = r
> accountA = rw
> accountB = rw
>
>
> The rationale for this restriction is this: if we allow the same section
> to appear multiple times, it becomes too hard to determine in which
> order the rules should be applied and which rules take precedence. This
> was not such an issue before when a section name (path) was always an
> exact match (although q.v. global vs. repository-specific rules, too).
> With wildcards, it's much easier to write multiple sections that match
> the same concrete path; so we must have a consistent way to determine
> which rule actually applies.
>
> Consider, supposing we allowed repeating sections:
>
> [:glob:/foo/*]
> $authenticated = r
>
> [/foo/bar]
> accountA = rw
>
> [:glob:/foo/*]
> accountA =
>
>
> When we look at /foo/bar in a repository as accountA, what should
> happen? Our current behavour is, IIRC, that the rule that was defined
> last wins ... but which is last in this case? There are two possible
> answers, which means there's too much room for confusion. Hence the
> restriction.
>

Makes perfect sense. Thank you!

> Can you say more about the "value expansion"?
>
> In Subversion config files you can write something like this:
>
> [DEFAULT]
> foo = bar
>
> [section]
> option = %(foo)s
>
>
> which will be equivalent to:
>
> [section]
> option = bar
>
>
> In other words, we support variable expansion similar to Python's
> ConfigParser module. Because we used to have the same parser for authz
> files as for config files, this misfeature was also supported in authz
> files. The new parser does not support variable expansion.
>

Great that was never documented! Ugh.

Thank you again - cheers!

Doug

-- 
*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.