You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Thomas Quinot <qu...@adacore.com> on 2018/02/14 09:46:57 UTC
[PATCH] Virtual host mode with user name in URL
Bug reproduced on Debian GNU/Linux 9 with trunk version as of
revision 1824204, building with default options.
When operating svnserve in virtual host mode (--virtual-host),
any attempt to access a repository through a URL that includes
a user name will fail:
$ mkdir -p /tmp/repos/localhost
$ svnadmin create /tmp/repos/localhost/Dev
$ svnserve -r /tmp/repos -d --virtual-host
$ svn ls svn://localhost/Dev
<works, returning empty result>
$ svn ls svn://foo@localhost/Dev
svn: E170013: Unable to connect to a repository at URL 'svn://foo@localhost/Dev'
svn: E210005: No repository found in 'svn://foo@localhost/Dev'
The reason for this is that svnserve will in this case include
the user name in the repository path, which can be shown
as follows:
$ ln -s localhost /tmp/repos/foo@localhost
$ svn ls svn://foo@localhost/Dev
<now works>
$ svn ls svn://bar@localhost/Dev
svn: E170013: Unable to connect to a repository at URL 'svn://bar@localhost/Dev'
svn: E210005: No repository found in 'svn://bar@localhost/Dev'
A simple fix is attached.
--
Thomas Quinot, Ph.D. ** quinot@adacore.com ** IT Lead Engineer
AdaCore -- Paris, France -- New York, USA
Re: [PATCH] Virtual host mode with user name in URL
Posted by Branko Čibej <br...@apache.org>.
On 15.02.2018 16:54, Thomas Quinot wrote:
> * Philip Martin, 2018-02-15 :
>
>> That looks correct so far, but it leads me to consider port numbers.
>>
>> svn ls svn://hostname:3691/repo
>>
>> Should the server look for the repository under 'hostname:3691' or under
>> the plain 'hostname'? I suspect the port number should be ignored and
>> that the plain 'hostname' is correct and that makes the current
>> behaviour another bug. We might be better off using apr_uri_parse()
>> rather than writing our own parsing code here.
> Thanks for your feedback Philip!
>
> I also thought about port numbers, and I think that's a different
> situations. I would view URLs differring only in the user name:
> svn://svn.example.com/
> svn://foo@svn.example.com/
> svn://bar@svn.example.com/
> as "clearly" referring to the same server/repo in all three cases.
Yes.
> On the other hand, I can see legitimate use cases where:
> svn://svn.example.com/
> svn://svn.example.com:3691/
> would refer to *different* servers/repos, in which case it makes sense
> to *include* the port number in the path when operating in virtual host
> mode.
Only if the port number isn't the default svn:// protocol port. If it
is, it should resolve to the same virtual host.
> Conversely, in use cases where the intent actually is for both
> URLs to denote the same underlying server, one can use a
> symbolic link svn.example.com:3691 -> svn.example.com.
You can't use symbolic links on all platforms, so that's not a solution.
Nor can you use a colon in directory names on all platforms, so the
vhost directory naming is a bit tricky here.
-- Brane
Re: [PATCH] Virtual host mode with user name in URL
Posted by Thomas Quinot <qu...@adacore.com>.
* Philip Martin, 2018-02-15 :
> That looks correct so far, but it leads me to consider port numbers.
>
> svn ls svn://hostname:3691/repo
>
> Should the server look for the repository under 'hostname:3691' or under
> the plain 'hostname'? I suspect the port number should be ignored and
> that the plain 'hostname' is correct and that makes the current
> behaviour another bug. We might be better off using apr_uri_parse()
> rather than writing our own parsing code here.
Thanks for your feedback Philip!
I also thought about port numbers, and I think that's a different
situations. I would view URLs differring only in the user name:
svn://svn.example.com/
svn://foo@svn.example.com/
svn://bar@svn.example.com/
as "clearly" referring to the same server/repo in all three cases.
On the other hand, I can see legitimate use cases where:
svn://svn.example.com/
svn://svn.example.com:3691/
would refer to *different* servers/repos, in which case it makes sense
to *include* the port number in the path when operating in virtual host
mode.
Conversely, in use cases where the intent actually is for both
URLs to denote the same underlying server, one can use a
symbolic link svn.example.com:3691 -> svn.example.com.
Unlike the set of user names, I would expect the set of ports
for which an svnserve process is listening to be "small" and "static"
enough that this is a viable approach.
Good remark about apr_uri_parse. Not clear it will substantially
simplify the code (will require introducing an apr_sprintf call,
and potentially conditional code depending on if and when a port
number needs to be explicitly included), but certainly cleaner from
a conceptual standpoint.
--
Thomas Quinot, Ph.D. ** quinot@adacore.com ** IT Lead Engineer
AdaCore -- Paris, France -- New York, USA
Re: [PATCH] Virtual host mode with user name in URL
Posted by Philip Martin <ph...@codematters.co.uk>.
Thomas Quinot <qu...@adacore.com> writes:
> [[[
> Fix failure to find repo in virtual host mode if user name present
>
> * subversion/svnserve/serve.c
> (find_repos): In vhost mode, skip past user name and password,
> if present.
> ]]]
>
> Index: subversion/svnserve/serve.c
> ===================================================================
> --- subversion/svnserve/serve.c (revision 1824204)
> +++ subversion/svnserve/serve.c (working copy)
> @@ -3806,12 +3806,21 @@ find_repos(const char *url,
> return svn_error_createf(SVN_ERR_BAD_URL, NULL,
> "Non-svn URL passed to svn server: '%s'", url);
>
> - if (! vhost)
> + /* In virtual host mode, skip past any USER[:PASSWORD]@ part,
> + else skip past [USER[:PASSWORD]@]HOST/. */
> + if (vhost)
> {
> + const char *h_path = strchr(path, '@');
> + if (h_path != NULL)
> + path = h_path + 1;
> + }
> + else
> + {
> path = strchr(path, '/');
> if (path == NULL)
> path = "";
> }
That looks correct so far, but it leads me to consider port numbers.
svn ls svn://hostname:3691/repo
Should the server look for the repository under 'hostname:3691' or under
the plain 'hostname'? I suspect the port number should be ignored and
that the plain 'hostname' is correct and that makes the current
behaviour another bug. We might be better off using apr_uri_parse()
rather than writing our own parsing code here.
--
Philip