On Tue, Jul 29, 2014 at 12:46 PM, Branko Čibej <br...@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
