Logging Subversion client HTTP requests
Hello, I am writing a small SubVersion client library independent of the svn client command. My library works well but for some reason it does not work with a certain SSL server that is not under my control. It returns error 400. I assume I am sending some malformed commands. On the other hand the svn client command works well. I tried to use strace to see what svn does different but since it is all in SSL I cannot see the HTTP requests and responses in the strace output because it is all encrypted. Is there a way to log the svn client HTTP traffic to a file so I can examine and compare the requests being sent and responses being received? -- Regards, Manuel Lemos
Re: Logging Subversion client HTTP requests
Hi Manuel, On Sat, Jul 30, 2011 at 12:16 PM, Manuel Lemos mle...@acm.org wrote: Hello, I am writing a small SubVersion client library independent of the svn client command. My library works well but for some reason it does not work with a certain SSL server that is not under my control. It returns error 400. I assume I am sending some malformed commands. On the other hand the svn client command works well. I tried to use strace to see what svn does different but since it is all in SSL I cannot see the HTTP requests and responses in the strace output because it is all encrypted. Is there a way to log the svn client HTTP traffic to a file so I can examine and compare the requests being sent and responses being received? Are you not using the libsvn_* libraries? libsvn_client is specifically meant to build Subversion clients other than the standard command line client: Subclipse, AnkhSVN, TortoiseSVN and others are all based on it. When using those libraries, you don't have to be worried to emulate the protocol correctly. Basically, you can build your own client on the vast experience of the Subversion developers. The other libraries allow you to interact as a Subversion client on different levels in the stack, libsvn_ra for example will allow you to interact with a Subversion server without having a local working copy. The above is not only directed at you, btw, it's a message to everybody who is planning to write a Subversion client. Bye, Erik.
Worst Error Message?
I just spent all day working on a bug. I could create a repository, and could do svn checkout ... but when I did svn commit I got this error message: svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/Mummy/!svn/act/991016fc-bbae-4269-a468-b8e3d9bce7b5' Late that night, it finally hit to me: I had read access to the repository, but not write access. My procedure for creating a repository did not grant write access to the creator. That is close to the worst error message I have ever seen.
Re: Worst Error Message?
On Sat, 30 Jul 2011, Andy Canfield wrote: I just spent all day working on a bug. I could create a repository, and could do svn checkout ... but when I did svn commit I got this error message: svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/Mummy/!svn/act/991016fc-bbae-4269-a468-b8e3d9bce7b5' Late that night, it finally hit to me: I had read access to the repository, but not write access. My procedure for creating a repository did not grant write access to the creator. That is close to the worst error message I have ever seen. then you've never seen a problem of type 2094: http://www.youtube.com/watch?v=rL2blQ2PlU4 rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: Worst Error Message?
On Sat, Jul 30, 2011 at 09:15:18PM +0700, Andy Canfield wrote: I just spent all day working on a bug. I could create a repository, and could do svn checkout ... but when I did svn commit I got this error message: svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/Mummy/!svn/act/991016fc-bbae-4269-a468-b8e3d9bce7b5' Late that night, it finally hit to me: I had read access to the repository, but not write access. My procedure for creating a repository did not grant write access to the creator. That is close to the worst error message I have ever seen. Yeah, that's one is bad. I gave a talk about this topic on svnday in May this year: http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf
Re: disable security hole in svn+ssh?
On 07/29/2011 02:10 PM, Cooke, Mark wrote: -Original Message- From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] Sent: 29 July 2011 02:27 To: Geoff Hoffman Cc: Nico Kadel-Garcia; users@subversion.apache.org Subject: Re: disable security hole in svn+ssh? snip Apparently, regardless of the protocol, the Subversion library code always checks $SVNParentPath/$Repository/conf/* and obeys svnserve.conf and authz. So I need to learn to use that effectively. snip I am fairly certain that you are wrong about this, only svnserve looks at the svnserve.conf and I believe that you can safely remove this file if you do not use svnserve. In fact the first lines of the default file are: ### This file controls the configuration of the svnserve daemon, if you ### use it to allow access to this repository. (If you only allow ### access through http: and/or file: URLs, then this file is ### irrelevant.) Apache httpd access would not use it at all and will only apply authz if you use the AuthzSVNAccessFile directive... ~ mark c WHOA! Things are getting re-arranged in my mind. Now I think that svnserve has no global authz file at all, and only relies on the individual authz file in the conf subdirectory in each repository, whereas mod_dav_svn relies on a global authz file identified by the AuthzSVNAccessFile in dav_svn.conf. Does mod_dav_svn check the individual authz file in the directory, also? Or does it rely solely on the global authz file? Is this true? My current create.php script replaces $SVNParentPath/REPOSITORY/conf/authz with a symbolic link to $SVNParentPath/conf/authz (which is where my AuthzSVNAccessFile points). This gives the same authorizations across the entire repository collection.
Re: Worst Error Message?
On 07/30/2011 09:31 PM, Stefan Sperling wrote: On Sat, Jul 30, 2011 at 09:15:18PM +0700, Andy Canfield wrote: I just spent all day working on a bug. I could create a repository, and could do svn checkout ... but when I did svn commit I got this error message: svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/Mummy/!svn/act/991016fc-bbae-4269-a468-b8e3d9bce7b5' Late that night, it finally hit to me: I had read access to the repository, but not write access. My procedure for creating a repository did not grant write access to the creator. That is close to the worst error message I have ever seen. Yeah, that's one is bad. I gave a talk about this topic on svnday in May this year: http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf Great PDF. But I would add something at the end: What can Stefan Sperling do? He can post an HTML version of this onto subversion.apache.org so that when users see one of these insane messages they can google for it, and find a rational explanation. Thanks.
Re: Worst Error Message?
On 7/30/11 9:15 AM, Andy Canfield wrote: I just spent all day working on a bug. I could create a repository, and could do svn checkout ... but when I did svn commit I got this error message: svn: Commit failed (details follow): svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/svn/Mummy/!svn/act/991016fc-bbae-4269-a468-b8e3d9bce7b5' Late that night, it finally hit to me: I had read access to the repository, but not write access. My procedure for creating a repository did not grant write access to the creator. Ummm, if it hurts, don't do it. That is close to the worst error message I have ever seen. You haven't been doing complicated things with a computer long, I take it. There are plenty of worse messages on the order of can't happen'. '403 forbidden' makes reasonable sense for a client-side message to someone who shouldn't know internal details anyway. Is something better in the apache error log where the sysadmin who set it up wrong should be looking? -- Les Mikesell lesmikes...@gmail.com
Re: Worst Error Message?
On 30 Jul 2011, at 18:17, Les Mikesell wrote: '403 forbidden' makes reasonable sense for a client-side message to someone who shouldn't know internal details anyway. Seriously? You think an HTTP response code (which *is* an internal detail) is an acceptable error message. You think it makes sense? Why is 403 forbidden? Oh, right, that's just a code. Ok what is forbidden? Is it me? the repository? writing to the repository? writing to a particular file? Why is it forbidden? Is it because it is Tuesday? WHY??? It's a useless error message. It's even pretty useless to the average person when they are trying to use a browser to access a URL. Is something better in the apache error log where the sysadmin who set it up wrong should be looking? Except that the administrator might not have set up the repository wrong. He might have made it deliberately read only. Users should not have to trawl Apache logs to find out that they are not allowed to commit to a repository. -- Les Mikesell lesmikes...@gmail.com
Re: Worst Error Message?
On 7/30/11 1:14 PM, Jeremy Pereira wrote: On 30 Jul 2011, at 18:17, Les Mikesell wrote: '403 forbidden' makes reasonable sense for a client-side message to someone who shouldn't know internal details anyway. Seriously? You think an HTTP response code (which *is* an internal detail) is an acceptable error message. You think it makes sense? Why is 403 forbidden? Oh, right, that's just a code. Ok what is forbidden? Is it me? the repository? writing to the repository? writing to a particular file? Why is it forbidden? Is it because it is Tuesday? WHY??? It's a useless error message. It's even pretty useless to the average person when they are trying to use a browser to access a URL. From a security perspective it is a bad idea to tell a network client that is doing something you have explicitly denied any of the details of how the system is configured to prevent it. Working correctly is usually a yes or no question and this answer is clearly 'no'. Is something better in the apache error log where the sysadmin who set it up wrong should be looking? Except that the administrator might not have set up the repository wrong. He might have made it deliberately read only. Users should not have to trawl Apache logs to find out that they are not allowed to commit to a repository. Right, if the system is intentionally set up for read-only access, the user should not get a hint about how to work around it, and it won't do them any particular good to know if it is denied in the http config, the authorization setup, or the filesystem. Really, what do you need to know as an end user besides that your commit was denied? -- Les Mikesell lesmikes...@gmail.com
Re: Worst Error Message?
On Sat, Jul 30, 2011 at 3:10 PM, Les Mikesell lesmikes...@gmail.com wrote: On 7/30/11 1:14 PM, Jeremy Pereira wrote: On 30 Jul 2011, at 18:17, Les Mikesell wrote: '403 forbidden' makes reasonable sense for a client-side message to someone who shouldn't know internal details anyway. Seriously? You think an HTTP response code (which *is* an internal detail) is an acceptable error message. You think it makes sense? Why is 403 forbidden? Oh, right, that's just a code. Ok what is forbidden? Is it me? the repository? writing to the repository? writing to a particular file? Why is it forbidden? Is it because it is Tuesday? WHY??? It's a useless error message. It's even pretty useless to the average person when they are trying to use a browser to access a URL. From a security perspective it is a bad idea to tell a network client that is doing something you have explicitly denied any of the details of how the system is configured to prevent it. Working correctly is usually a yes or no question and this answer is clearly 'no'. Is something better in the apache error log where the sysadmin who set it up wrong should be looking? Except that the administrator might not have set up the repository wrong. He might have made it deliberately read only. Users should not have to trawl Apache logs to find out that they are not allowed to commit to a repository. Right, if the system is intentionally set up for read-only access, the user should not get a hint about how to work around it, and it won't do them any particular good to know if it is denied in the http config, the authorization setup, or the filesystem. Really, what do you need to know as an end user besides that your commit was denied? When I, as a user, am denied access to something, it's very helpful to know at which level of the setup my access was denied in order to *fix* it. And it's helpful for me, as an admin, to get an error message that reveals as much as possible about the problem so that I can fix it if the problem is my fault.
Re: Logging Subversion client HTTP requests
Hello, on 07/30/2011 07:18 AM Ryan Schmidt said the following: On Jul 30, 2011, at 05:16, Manuel Lemos wrote: Is there a way to log the svn client HTTP traffic to a file so I can examine and compare the requests being sent and responses being received? You mean like this? http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.logging No, I have no control over the server. Or did you mean on the client side? If so I don't know. OK, thanks anyway. -- Regards, Manuel Lemos JS Classes - Free ready to use OOP components written in JavaScript http://www.jsclasses.org/
Re: Logging Subversion client HTTP requests
Hello Erik, on 07/30/2011 09:00 AM Erik Huelsmann said the following: Hi Manuel, On Sat, Jul 30, 2011 at 12:16 PM, Manuel Lemos mle...@acm.org mailto:mle...@acm.org wrote: Hello, I am writing a small SubVersion client library independent of the svn client command. My library works well but for some reason it does not work with a certain SSL server that is not under my control. It returns error 400. I assume I am sending some malformed commands. On the other hand the svn client command works well. I tried to use strace to see what svn does different but since it is all in SSL I cannot see the HTTP requests and responses in the strace output because it is all encrypted. Is there a way to log the svn client HTTP traffic to a file so I can examine and compare the requests being sent and responses being received? Are you not using the libsvn_* libraries? libsvn_client is specifically meant to build Subversion clients other than the standard command line client: Subclipse, AnkhSVN, TortoiseSVN and others are all based on it. When using those libraries, you don't have to be worried to emulate the protocol correctly. Basically, you can build your own client on the vast experience of the Subversion developers. The other libraries allow you to interact as a Subversion client on different levels in the stack, libsvn_ra for example will allow you to interact with a Subversion server without having a local working copy. The above is not only directed at you, btw, it's a message to everybody who is planning to write a Subversion client. Sorry, I did not mention that I am writing a pure PHP client that needs to run on an environment on which the svn program is not available, nor any SubVersion PHP extensions are available. So using anything based on libsvn is not an option for me unfortunately. Anyway, I tried to hack SubVersion program code to insert some debug code to output the HTTP dialog but I got lost and could not figure where exactly the HTTP requests and responses are sent. Anybody, knows where exactly is the code that sends and receives HTTP requests so I can hack it to just add some debug output in my svn command copy in order to see the HTTP dialog? -- Regards, Manuel Lemos JS Classes - Free ready to use OOP components written in JavaScript http://www.jsclasses.org/
Re: Logging Subversion client HTTP requests
On Jul 30, 2011, at 17:35, Manuel Lemos wrote: on 07/30/2011 09:00 AM Erik Huelsmann said the following: Are you not using the libsvn_* libraries? libsvn_client is specifically meant to build Subversion clients other than the standard command line client: Subclipse, AnkhSVN, TortoiseSVN and others are all based on it. When using those libraries, you don't have to be worried to emulate the protocol correctly. Basically, you can build your own client on the vast experience of the Subversion developers. The other libraries allow you to interact as a Subversion client on different levels in the stack, libsvn_ra for example will allow you to interact with a Subversion server without having a local working copy. Sorry, I did not mention that I am writing a pure PHP client that needs to run on an environment on which the svn program is not available, nor any SubVersion PHP extensions are available. So using anything based on libsvn is not an option for me unfortunately. That's ridiculous. Use an svn php extension. Or if you must, call the svn command line program. Don't reinvent the wheel, because you probably won't get it quite right, and you'll cause weird error messages or possibly even repository corruption.
Re: Logging Subversion client HTTP requests
Hello, on 07/30/2011 07:42 PM Ryan Schmidt said the following: Sorry, I did not mention that I am writing a pure PHP client that needs to run on an environment on which the svn program is not available, nor any SubVersion PHP extensions are available. So using anything based on libsvn is not an option for me unfortunately. That's ridiculous. Use an svn php extension. Or if you must, call the svn command line program. Don't reinvent the wheel, because you probably won't get it quite right, and you'll cause weird error messages or possibly even repository corruption. Maybe I was not clear, but I really need to access SubVersion repositories in third-party environments on which there is no subversion client nor any PHP SubVersion extension. I can already do it to access CVS and Git repositories, there is no reason I cannot do it for SubVersion. I understand what you are saying not getting it quite right, but I do not have an option, so I have to do it all in pure PHP. I have already a pure PHP implementation working with most repositories but I am getting error 400 when accessing some repositories over HTTPS and I could not figure what am I doing differently. I am also skilled in C programming for many years but that is not an option to run my code in environments that I do not control. So, would you be able to be so kind to help locating the svn command code that I need to hack to make it show the HTTP dialog? -- Regards, Manuel Lemos JS Classes - Free ready to use OOP components written in JavaScript http://www.jsclasses.org/
Re: Logging Subversion client HTTP requests
On Jul 30, 2011, at 17:56, Manuel Lemos wrote: on 07/30/2011 07:42 PM Ryan Schmidt said the following: Sorry, I did not mention that I am writing a pure PHP client that needs to run on an environment on which the svn program is not available, nor any SubVersion PHP extensions are available. So using anything based on libsvn is not an option for me unfortunately. That's ridiculous. Use an svn php extension. Or if you must, call the svn command line program. Don't reinvent the wheel, because you probably won't get it quite right, and you'll cause weird error messages or possibly even repository corruption. Maybe I was not clear, but I really need to access SubVersion repositories in third-party environments on which there is no subversion client nor any PHP SubVersion extension. I can already do it to access CVS and Git repositories, there is no reason I cannot do it for SubVersion. I understand what you are saying not getting it quite right, but I do not have an option, so I have to do it all in pure PHP. I have already a pure PHP implementation working with most repositories but I am getting error 400 when accessing some repositories over HTTPS and I could not figure what am I doing differently. I am also skilled in C programming for many years but that is not an option to run my code in environments that I do not control. So, would you be able to be so kind to help locating the svn command code that I need to hack to make it show the HTTP dialog? I'm not able to help with that because I'm not familiar with the Subversion source code. But you understand why even if I knew I would be disinterested in helping you. The Subversion libraries have been in development for 11 years, work great, and do exactly what you want, but you're saying nope, you're going to recreate them from scratch, except it doesn't work all the time, so you ask for help from the group that answers questions about the libraries, whose members are obviously going to say this is an already solved non-problem: use the libraries. If you can install PHP, why can't you install the Subversion libraries and PHP extension? The Subversion libraries are going to continue to evolve, as is the network protocol. For example, Subversion used to only be able to use neon for talking to http servers, but now can use serf which perhaps offers better performance, and serf becomes the default in Subversion 1.7; which of these methods are you emulating? So this isn't even a one-time task you're contemplating; this is an ongoing duplicate maintenance effort you're committing yourself to.
Re: Logging Subversion client HTTP requests
On Sat, Jul 30, 2011 at 3:56 PM, Manuel Lemos mle...@acm.org wrote: I have already a pure PHP implementation Manuel, didn't you also write whole Mailer library for PHPClasses.org and start that site? When do you sleep? You're speaking to svn server directly from PHP, with stream context or exec( ) bridge somehow? I'm curious now.
Re: Logging Subversion client HTTP requests
Hello Ryan, on 07/30/2011 08:30 PM Ryan Schmidt said the following: Sorry, I did not mention that I am writing a pure PHP client that needs to run on an environment on which the svn program is not available, nor any SubVersion PHP extensions are available. So using anything based on libsvn is not an option for me unfortunately. That's ridiculous. Use an svn php extension. Or if you must, call the svn command line program. Don't reinvent the wheel, because you probably won't get it quite right, and you'll cause weird error messages or possibly even repository corruption. Maybe I was not clear, but I really need to access SubVersion repositories in third-party environments on which there is no subversion client nor any PHP SubVersion extension. I can already do it to access CVS and Git repositories, there is no reason I cannot do it for SubVersion. I understand what you are saying not getting it quite right, but I do not have an option, so I have to do it all in pure PHP. I have already a pure PHP implementation working with most repositories but I am getting error 400 when accessing some repositories over HTTPS and I could not figure what am I doing differently. I am also skilled in C programming for many years but that is not an option to run my code in environments that I do not control. So, would you be able to be so kind to help locating the svn command code that I need to hack to make it show the HTTP dialog? I'm not able to help with that because I'm not familiar with the Subversion source code. OK, I understand. But you understand why even if I knew I would be disinterested in helping you. The Subversion libraries have been in development for 11 years, work great, and do exactly what you want, but you're saying nope, you're going to recreate them from scratch, except it doesn't work all the time, so you ask for help from the group that answers questions about the libraries, whose members are obviously going to say this is an already solved non-problem: use the libraries. Trust me, I would rather rely on the svn command precisely because what you said, after 11 years of development it can handle all the quirks of all the WebDAV version variants and bugs. I am not masochist. I do not want to deal with all that if I had a choice. If you can install PHP, why can't you install the Subversion libraries and PHP extension? I can install whatever I want in my servers, but I am developing a SubVersion client that will run on third party shared hosting servers which do not have the svn program installed. So I have to rely on PHP net access support. That is why. The Subversion libraries are going to continue to evolve, as is the network protocol. For example, Subversion used to only be able to use neon for talking to http servers, but now can use serf which perhaps offers better performance, and serf becomes the default in Subversion 1.7; which of these methods are you emulating? So this isn't even a one-time task you're contemplating; this is an ongoing duplicate maintenance effort you're committing yourself to. I am well aware of that, but I hope now you understand why that option is not available to me. BTW, is there any documentation for that serf library so I can figure how it is used in the svn command? -- Regards, Manuel Lemos JS Classes - Free ready to use OOP components written in JavaScript http://www.jsclasses.org/
Re: Logging Subversion client HTTP requests
Hello, on 07/30/2011 09:16 PM Geoff Hoffman said the following: I have already a pure PHP implementation Manuel, didn't you also write whole Mailer library for PHPClasses.org and start that site? When do you sleep? hahah good question. When you work full time on these stuff you do it for pleasure and too bad sleep does not allow you to do more in less time! :-) You're speaking to svn server directly from PHP, with stream context or exec( ) bridge somehow? I'm curious now. Actually I am using a long standing HTTP client which uses fsockopen by default but it can optionally switch to Curl for SSL requests. http://www.phpclasses.org/httpclient Either way there is at least one SubVersion host on SSL (BeanstalkApp) which is returning error 400 all the time. https://sschlapkohl.svn.beanstalkapp.com/htmlform/trunk/ Anyway, I just realized if I use file_get_contents (with default stream context) which just sends a simple GET request with one Host: header, it works. So there is something specific to that Web server that is balking all requests with status 400. I suspect that it is not even related with SubVersion because even GET requests fail. Just let me know if you have any idea. -- Regards, Manuel Lemos JS Classes - Free ready to use OOP components written in JavaScript http://www.jsclasses.org/ -- Regards, Manuel Lemos JS Classes - Free ready to use OOP components written in JavaScript http://www.jsclasses.org/
Re: Logging Subversion client HTTP requests
On Sat, Jul 30, 2011 at 6:20 PM, Manuel Lemos mle...@acm.org wrote: Hello, on 07/30/2011 09:16 PM Geoff Hoffman said the following: I have already a pure PHP implementation Manuel, didn't you also write whole Mailer library for PHPClasses.org and start that site? When do you sleep? hahah good question. When you work full time on these stuff you do it for pleasure and too bad sleep does not allow you to do more in less time! :-) You're speaking to svn server directly from PHP, with stream context or exec( ) bridge somehow? I'm curious now. Actually I am using a long standing HTTP client which uses fsockopen by default but it can optionally switch to Curl for SSL requests. http://www.phpclasses.org/**httpclienthttp://www.phpclasses.org/httpclient Either way there is at least one SubVersion host on SSL (BeanstalkApp) which is returning error 400 all the time. https://sschlapkohl.svn.**beanstalkapp.com/htmlform/**trunk/https://sschlapkohl.svn.beanstalkapp.com/htmlform/trunk/ Anyway, I just realized if I use file_get_contents (with default stream context) which just sends a simple GET request with one Host: header, it works. So there is something specific to that Web server that is balking all requests with status 400. I suspect that it is not even related with SubVersion because even GET requests fail. Just let me know if you have any idea. Does httpclient work if you switch it to the cURL option? You may need to extend the class to provide https specific curl options [1]. [1] http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/
Re: Logging Subversion client HTTP requests
Hello, on 07/30/2011 10:57 PM Geoff Hoffman said the following: Does httpclient work if you switch it to the cURL option? You may need to extend the class to provide https specific curl options [1]. [1] http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/ I just figured the problem. It was not working with Curl either because I was resolving the IP address of the server before opening the SSL connection and I should have used the original host name for servers like this for some reason related with the way PHP establishes SSL connections. Anyway, this problem is solved now. Thanks for the interest in helping out. I still have a problem with CodePlex SubVersion, which is also accSSL, but I think I will figure out comparing with requests sent by the svn program to non-SSL sites. I will let you know otherwise. -- Regards, Manuel Lemos JS Classes - Free ready to use OOP components written in JavaScript http://www.jsclasses.org/
Re: SVNParent authz
On 07/29/2011 01:48 PM, Cooke, Mark wrote: -Original Message- From: Andy Canfield [mailto:andy.canfi...@pimco.mobi] Sent: 29 July 2011 05:14 To: users@subversion.apache.org Subject: SVNParent authz I am having a problem with AuthzSVNAccessFile. Consider the case where I have two repositories, R1 and R2 Some users are authorized to examine R1 by going to http://example.com/svn/R1 Other users are authorized to examine R2 by going to http://example.com/svn/R2 But everyone should be able to see the list of repositories by going to http://example.com/svn I can't get that to work. I am having a problem with the mod_dav_svn.conf command: AuthzSVNAccessFile /Subversion/conf/authz If I have AuthzSVNAccessFile turned off (commented out), then all users can see the contents of all repositories. But if I have AuthzSVNAccssFile turned on, then nobody is authorized to see the list of repositories via http://example.com/svn; because I can't figure out how to set authz to give read access to the repository collection but limited access to the individual repositories. Here is my closest guess for authz - [groups] everyone = andy,fred [/] @everyone = r [subdoc:/] andy = rw The [/] section is the part that is incorrect. How can I give everyone read access to http:///example.com/svn; without giving them read access to http://example.com/svn/subdoc; ? Indeed, it seems as if the instant I turn on AuthzSVNAccessFile nobody can read http://example.com/svn; at all. Thank you for your patience. There was a bug relating to authz which meant that users had to have access to the root to see anything, you do not mention which version you are using? Version: 1.6.12dfsg-4ubuntu2.1 Note that you can remove permissions as well as grant them, so something like this should work... [groups] everyone = andy,fred [/] @everyone = r [R1:/] andy = rw fred = [R2:/] andy = fred = rw If that does not work, can you post the relevant bits of your apache conf and also which versions and platforms you are on. For example, I use the following for our windoze based repos: Location /svn/ DAV svn SVNParentPath D:/svn/root/ SVNListParentPath On # restrict access to subversion repository paths... AuthzForceUsernameCase Lower AuthzSVNAccessFile D:/path/to/svn-users.txt /Location ~ mark c Thanks. Built my own web page to do the list of repositories. My page shows megabytes, user and date of last revision, and includes a button to create a new repository. Goes in through PHP, not via SVNListParentPath. Access controlled by Apache not Subversion. Works OK. So we seem to be ready to fly here. Thanks to all.
Re: Logging Subversion client HTTP requests
On Sat, 30 Jul 2011 18:30:11 +, Ryan Schmidt wrote: ... But you understand why even if I knew I would be disinterested in helping you. The Subversion libraries have been in development for 11 years, work great, They work so great that you can't even Ctrl-C the svn command line client in the connection phase, and instead need to resort to ^Z and 'kill -9 %'. (Ok, this may not actually be a problem with *lib*svn.) ... The Subversion libraries are going to continue to evolve, as is the network protocol. For example, Subversion used to only be able to use neon for talking to http servers, but now can use serf which perhaps offers better performance, and serf becomes the default in Subversion 1.7; which of these methods are you emulating? If he is going to talk on the level of http requests directly, neon-vs.-serf is a complete non-question. The interesting point is that as far as I know there is a complete change in the http-level protocol coming up, to avoid the massive round-trip count the current method needs. (But that's a maintenance nightmare for libsvn as well as for anybody else writing a bare-net client.) So this isn't even a one-time task you're contemplating; this is an ongoing duplicate maintenance effort you're committing yourself to. Yes, it is. But it's not your problem, and I don't see why the http 'wire' protocol needs to be a undocumented secret. Using a C library is *not* always an option; for example having a pure java client library available would be a big help for java-implemented IDEs. And there already *are* parties that talk svn http directly; github has readonly svn access, and codeplex is also emulating somehow. Neither do I expect google code to use the original apache svn server code. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800
