Re: [viewvc-dev] svnauthz using svn bindings

------=_Part_10711_803416890.1450450324786
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The Subversion bindings aren't used in the ViewVC svnauthz authorizer
because that authorizer can be applied both to CVS repositories as well as
to remote Subversion repositories (those configured with URL rootpaths).  I
wouldn't be opposed, however, to introducing another authorizer which is
built around the Subversion APIs and is only applicable to locally
accessible Subversion repositories.

Out of curiosity, though, what is it about the current authorizer that's
insufficient for your needs?

-- Mike

On Mon, Dec 14, 2015 at 11:36 AM, Phil Richardson <[email protected]>
wrote:

> I am currently using experimental features from future subversion
> releases. These specifically impact my ability to use the svnauthz
> authorizer.
>
> One thing that cropped up that I could not locate a prior post regarding.
>
> Is there a reason why the svn bindings are not used to perform the authz
> logic?
>
> Attached is a replacement which I used under the module svnauthzbindings
>
> This essentially proxies through what svn itself implements. The exception
> being I can only 1 in return check_root_access, otherwise access is denied
> (other path checking takes care of real access rules though).
>
> I'm also exploring the missing "authz in repositiory" as well, but it's
> not a problem for what I am doing right now.
>

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=3151285

To unsubscribe from this discussion, e-mail: [[email protected]].
------=_Part_10711_803416890.1450450324786
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The Subversion bindings aren&#39;t used in the ViewVC svna=
uthz authorizer because that authorizer can be applied both to CVS reposito=
ries as well as to remote Subversion repositories (those configured with UR=
L rootpaths).=C2=A0 I wouldn&#39;t be opposed, however, to introducing anot=
her authorizer which is built around the Subversion APIs and is only applic=
able to locally accessible Subversion repositories.<div><br></div><div>Out =
of curiosity, though, what is it about the current authorizer that&#39;s in=
sufficient for your needs?</div><div><br></div><div>-- Mike</div></div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Dec 14, 2015 =
at 11:36 AM, Phil Richardson <span dir=3D"ltr">&lt;<a href=3D"mailto:ppslim=
[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I am currently u=
sing experimental features from future subversion releases. These specifica=
lly impact my ability to use the svnauthz authorizer.<div><br></div><div>On=
e thing that cropped up that I could not locate a prior post regarding.</di=
v><div><br></div><div>Is there a reason why the svn bindings are not used t=
o perform the authz logic?</div><div><br></div><div>Attached is a replaceme=
nt which I used under the module svnauthzbindings</div><div><br></div><div>=
This essentially proxies through what svn itself implements. The exception =
being I can only 1 in return=C2=A0check_root_access, otherwise access is de=
nied (other path checking takes care of real access rules though).</div><di=
v><br></div><div>I&#39;m also exploring the missing &quot;authz in repositi=
ory&quot; as well, but it&#39;s not a problem for what I am doing right now=
.</div></div>
</blockquote></div><br></div>

------=_Part_10711_803416890.1450450324786--