Bug #21452 for SVN-Web: PerlAuthzHandler to parse and enforce an AuthzSVNAccessFile

Tue Sep 12 14:00:15 2006 matthew [...] veradox.com - Ticket created

Subject:

PerlAuthzHandler to parse and enforce an AuthzSVNAccessFile

a new module, SVN::Web::Authz or something, whose mod_perl2 handler() method parses an AuthzSVNAccessFile, whose location is optionally specified in the SVN::Web yaml config. Since SVN::Web is currently a read-only client, only enforce the read ACLs in the file. See http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir for the format of the AuthzSVNAccessFile. See http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthzHandler for a cookie cutter example on how to implement this. Then in the apache2 directory block where SVN::Web is set as the PerlHandler, you could have PerlAuthzHandler SVN::Web:Authz The handler() method could return its own "not authorized" templated error page, or let the SVN::Web handler do it later in the apache request cycle.

Tue Sep 12 14:42:40 2006 nik [...] ngo.org.uk - Correspondence added

Subject:	Re: [rt.cpan.org #21452] PerlAuthzHandler to parse and enforce an AuthzSVNAccessFile
Date:	Tue, 12 Sep 2006 19:42:17 +0100
To:	bug-SVN-Web [...] rt.cpan.org
From:	Nik Clayton <nik [...] ngo.org.uk>

Matthew Wilson via RT wrote: Show quoted text

> Tue Sep 12 14:00:15 2006: Request 21452 was acted upon. > Transaction: Ticket created by WILSON > Queue: SVN-Web > Subject: PerlAuthzHandler to parse and enforce an AuthzSVNAccessFile > Broken in: (no value) > Severity: Wishlist > Owner: Nobody > Requestors: matthew@veradox.com > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=21452 > > > > a new module, SVN::Web::Authz or something, whose mod_perl2 handler() > method parses an AuthzSVNAccessFile, whose location is optionally > specified in the SVN::Web yaml config. Since SVN::Web is currently a > read-only client, only enforce the read ACLs in the file.

Would it be acceptable if SVN::Web queried the repo for authentication information instead? I'm planning on using SVN::Client at the backend, instead of using SVN::Repos (or SVN::Ra) which should provide this sort of thing for free. If the repo requires a username and password I imagine that SVN::Web will use basic authentication (so you'd be advised to run it under https) to get the username and password, and then it will use those credentials when accessing the repo. This should then work irrespective of the web server that SVN::Web runs under. This is all a bit hypothetical at the moment. I've got SVN::Ra working as an access method (which was a big step) so going to SVN::Client should be a bit easier. But I don't know how much effort that's going to be yet. N

Tue Sep 12 14:42:41 2006 The RT System itself - Status changed from 'new' to 'open'

Tue Sep 12 14:57:12 2006 matthew [...] veradox.com - Correspondence added

Show quoted text

> Would it be acceptable if SVN::Web queried the repo for authentication > information instead?

That would be a great feature, in addition. But our authentication credentials and authorization ACLs are not enforced at that tier. We have a filesystem repository served by https, using apache's active directory authentication. Our authorization ACLs are stored in an AuthzSVNAccessFile. Show quoted text

> > I'm planning on using SVN::Client at the backend, instead of using > SVN::Repos (or SVN::Ra) which should provide this sort of thing for > free. If the repo requires a username and password I imagine that > SVN::Web will use basic authentication (so you'd be advised to run it > under https) to get the username and password, and then it will use > those credentials when accessing the repo.

That's great, but I don't plan on switching SVN::Web to access the repository via https, since that would be far slower, as far as I know. Show quoted text

> > This should then work irrespective of the web server that SVN::Web runs > under. > > This is all a bit hypothetical at the moment. I've got SVN::Ra working > as an access method (which was a big step) so going to SVN::Client > should be a bit easier. But I don't know how much effort that's going > to be yet. > > N

Tue Sep 12 16:00:18 2006 matthew [...] veradox.com - Correspondence added

I would be glad to write the package and handler skeleton, along with the AuthzSVNAccessFile parser (ACL builder). All that would be remaining is the enforcement/denial of access.

Wed Sep 13 09:00:59 2006 nik [...] ngo.org.uk - Correspondence added

Subject:	Re: [rt.cpan.org #21452] PerlAuthzHandler to parse and enforce an AuthzSVNAccessFile
Date:	Wed, 13 Sep 2006 14:00:40 +0100
To:	bug-SVN-Web [...] rt.cpan.org
From:	Nik Clayton <nik [...] ngo.org.uk>

Matthew Wilson via RT wrote: Show quoted text

>> Would it be acceptable if SVN::Web queried the repo for authentication >> information instead?

> > That would be a great feature, in addition. But our authentication > credentials and authorization ACLs are not enforced at that tier. We > have a filesystem repository served by https, using apache's active > directory authentication. Our authorization ACLs are stored in an > AuthzSVNAccessFile.

OK. Can you not use Apache URL based controls to limit access to SVN::Web? I'm not familiar with AuthzSVNAccessFile (yet), so that might be a silly question. Show quoted text

>> I'm planning on using SVN::Client at the backend, instead of using >> SVN::Repos (or SVN::Ra) which should provide this sort of thing for >> free. If the repo requires a username and password I imagine that >> SVN::Web will use basic authentication (so you'd be advised to run it >> under https) to get the username and password, and then it will use >> those credentials when accessing the repo.

> > That's great, but I don't plan on switching SVN::Web to access the > repository via https, since that would be far slower, as far as I know.

That's not quite what I mean. At the moment, SVN::Web can only talk to the repository if the repository is on a filesystem directly accessible by the SVN::Web process. When I switch to using SVN::Client you'll be able to specify repo access using Subversion urls. For example, repos: local: file:///path/to/repo svnweb: svn://jc.ngo.org.uk/ remote: http://some.host/path/to/repo With the svn:// and http:// accesses you should be able to piggy back on the same authorization policies that Subversion enforces for any other client. So if you need to make a part of your repository only readable to authorized users you should be able to do that. Then, when SVN::Web detects that the access needs authentication it will issue an HTTP Basic Auth challenge, prompting the browser to ask the user for a username and password. It's that last user/pass request that should probably run under https. N

Sun Feb 25 04:48:46 2018 dean [...] fragfest.com.au - Correspondence added

I doubt youre still interested in this. I will leave this as stalled in case anyone wants to submit a patch.

Sun Feb 25 04:48:46 2018 dean [...] fragfest.com.au - Status changed from 'open' to 'stalled'