On Fri, Apr 19, 2024 at 3:32 PM BK <b...@gmx.de> wrote:

> If the parser behaves like this in version 1.14, I take it as a given.
> I would be interested to know the reasons for this change?
>
The parsing change was actually made in 1.10.  It was done in order to
implement "wildcarding" in path-based AuthZ [0].
Background [1], additional information [2].

tl;dr: With the implementation of wildcarding the ordering of the sections
in the AuthZ file have become critical.

Also note: as of SVN 1.10 the parsing of the AuthZ file now takes longer.
Small AuthZ files won't likely see the issue but large AuthZ files can
cause user-visible delays from Apache/svnserve.  The workaround I've been
using is to break up the single "super" AuthZ files into per-repository
AuthZ files and use the Apache "AuthzSVNReposRelativeAccessFile" directive
(see example 4 in [3]).

> From the per repository point of view it didn't really help the clarity.
> But maybe there are more important reasons for the change.
>
I hope the above helps.

Cheers.

Doug
--
[0] https://subversion.apache.org/docs/release-notes/1.10.html#authzperf
[1] https://cwiki.apache.org/confluence/display/SVN/Authz+Improvements
[2] https://svn.haxx.se/dev/archive-2017-02/att-0188/
[3]
https://svn.apache.org/repos/asf/subversion/branches/1.10.x/subversion/mod_authz_svn/INSTALL


> Unfortunately, I don't have the expertise
> or sufficient programming knowledge to submit a patch.
>
> Best Regards,
> Bernhard
>
>
> Am 18.04.24 um 10:28 schrieb Daniel Sahlberg:
>
> The code as it is now seems to be very intentionally written to NOT allow
> multiple sections with the same name, see the check_open_section() function
> in authz_parse.c[1].
>
> I don't know if it would be possible to relax this restriction but feel
> free to take a look at the code and send a patch to
> d...@subversion.apache.org.
>
> It is not possible to switch back to the old authz parse code in version
> 1.14.
>
> Kind regards,
> Daniel
>
>

-- 
*Doug Robinson*  Senior Product Manager
P +1 925 396 1125
*E* doug.robin...@cirata.com

-- 





THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY 
BE PRIVILEGED


If this message was misdirected, Cirata Ltd. and its 
subsidiaries, ("Cirata") 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 Cirata, unless the author is authorized by Cirata 
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 Cirata. 
Although Cirata operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Reply via email to