On Tue, Jul 29, 2014 at 12:46 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 29.07.2014 12:25, Julian Foad wrote:
>
> Brane wrote:
>
> if the patterns were:
>
> [*/projects/f*/include/*.h]
> [*/projects/*o/include/*.h]
>
> (Ugh, I don't like the prefix '*' which I think you're using to mean
> 'wildcards enabled'.)
>
>
> I don't care what prefix we use, but I do care that the rules that contain
> wildcards have a different syntax than the rules that do not. Otherwise,
> existing authz files (that may contain literal wildcard/pattern characters)
> would stop working.
>
> We currently support two forms of patterns:
>
> [/literal-fspath]
> [repos:/literal-fspath]
>
> the distinguishing feature is that in both cases, the literal-fspath must
> begin with a slash, otherwise the rule is invalid. If we want to support
> wildcards, we have to invent a different syntax for wildcard rules. My
> working proposal is to add a literal '*' before the leading slash in the
> path:
>
> [*/fspath-pattern]
> [repos:*/fspath-pattern]
>
> because neither of these syntaxes are currently valid. We can invent a
> different syntax, as long as it maintains that property; and we cannot
> replace the brackets around the rule with something else, without making
> very intrusive changes in the config parser code.
Another approach might be to add an "options" section to the authz
file (in a way that it is ignored by older servers), where one could
specify a matching strategy (and if needed 'priority' strategy and so
on).
[options]
matching = literal | basic-wildcards | regex | ...
Then it's not hidden as a syntax-artifact, but more explicit ...
--
Johan
Received on 2014-07-29 12:56:22 CEST