Re: Support character classes in glob authz rules

Branko Čibej wrote:
>> If we treat the authz format as its own format, that does make me wonder if there are any other limitations the current ConfigParser format is applying, that should also be lifted.
>>
>> For example, if "@harry" is parsed as a reference to group name "harry", then is there also a way to specify a username that is literally "@harry"?
>
> Well, first of all, this has nothing to do with the ConfigParser, but
> with how our authz infrastructure interprets the access entry selectors.

Accepted.

> And no, there's no way to do this.
> > In general, is there a programmatic transformation from arbitrary valid user names and paths to corresponding authz entries?
>
> Define "arbitrary valid" and I'll answer that. :)

Ones that Subversion otherwise accepts, apart from in this context.

> We've always had the following restictions: usernames can't begin with
> '@' or '&' or '~',

There must be also limitations with '#', '*', '=' and whitespace characters, and I don't see a way to find a complete list.

> and similar limitations apply to group and alias
> names. Such identifiers have always been rejected at one stage or
> another, and this has not been a problem.

We haven't heard vocal complaints. It could well have caused headaches for those implementing authz in their systems. (Not because they need to use such usernames, but because they need to defensively program against an incompletely known set of problems.)

Would I be totally off the mark in suggesting an enhancement request for an authz file format that addresses these issues? It seems to me this is the sort of thing "enterprise" users would value.

-- 
- Julian