On 29.07.2014 12:55, Johan Corveleyn wrote: > 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 ...
Yes, well, I really don't want to go overboard with options here. The point of the exercise is to make current authz parsing a lot faster. If we can get in some basic wildcard support that doesn't affect users who do not use it, then fine; but confusing people with several different pattern syntaxes is too much. -- Brane -- Branko Čibej | Director of Subversion WANdisco | Realising the impossibilities of Big Data e. br...@wandisco.com
