Skip Menu |
 

This queue is for tickets about the SVN-Web CPAN distribution.

Report information
The Basics
Id: 21452
Status: stalled
Priority: 0/
Queue: SVN-Web

People
Owner: Nobody in particular
Requestors: matthew [...] veradox.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: PerlAuthzHandler to parse and enforce an AuthzSVNAccessFile
Download (untitled) / with headers
text/plain 824b
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.
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>
Download (untitled) / with headers
text/plain 1.4k
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
Download (untitled) / with headers
text/plain 1.2k
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
Download (untitled) / with headers
text/plain 180b
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.
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
Download (untitled) / with headers
text/plain 108b
I doubt youre still interested in this. I will leave this as stalled in case anyone wants to submit a patch.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.