subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Wischrop <Guido.Wisch...@mgm-tp.com>
Subject Re: svn: E170000: 'https://user:pass@x' isn't in the same repository as 'https://user:XXXXXXXX@x'
Date Tue, 08 Apr 2014 11:52:11 GMT

On 08.04.2014 13:30, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>> Sent: dinsdag 8 april 2014 12:19
>> To: users@subversion.apache.org; dev@subversion.apache.org
>> Cc: Bert Huijben
>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
> repository
>> as 'https://user:XXXXXXXX@x'
>>
>>
>> On 04.04.2014 17:40, Bert Huijben wrote:
>>>> -----Original Message-----
>>>> From: Guido Wischrop [mailto:Guido.Wischrop@mgm-tp.com]
>>>> Sent: vrijdag 4 april 2014 15:07
>>>> To: users@subversion.apache.org; dev@subversion.apache.org
>>>> Subject: Re: svn: E170000: 'https://user:pass@x' isn't in the same
>>> repository
>>>> as 'https://user:XXXXXXXX@x'
>>>>
>>>>
>>>> On 03.04.2014 12:47, Philip Martin wrote:
>>>>> Guido Wischrop <Guido.Wischrop@mgm-tp.com> writes:
>>>>>
>>>>>> I'm using win32svn, version 1.8.5 (r1542147) in Windows 7 x64 like
>>> this:
>>>>>> svn checkout https://user:pass@server/svn/p1/trunk
>>>>>>
>>>>>> I get the following error immediately:
>>>>>>
>>>>>> svn: E170000: 'https://user:pass@server/svn/p1/trunk' isn't in the
>> same
>>>>>> repository as 'https://user:XXXXXXXX@server/svn/p1/trunk'
>>>>>>
>>>>>> I tried SlikSVN (svn, version 1.8.5-SlikSvn-1.8.5-X64 (SlikSvn/1.8.5)
>>>>>> X64) with the same result.
>>>>>>
>>>>>> With version 1.7.1 or 1.6.5 (SlikSVN 1.7.1/win32svn) the same command
>>>>>> works as expected. Is the user:pass@server scheme no longer
>>>> supported?
>>>>> I get the same problem with trunk on Linux.  I can fix it with this
>>>>> patch but I'm not sure I understand all the consequences.  Is there
> any
>>>>> reason we should be hiding the password here?
>>>>>
>>>>> Index: subversion/libsvn_ra_serf/options.c
>>>>>
>> ==========================================================
>>>> =========
>>>>> --- subversion/libsvn_ra_serf/options.c	(revision 1584323)
>>>>> +++ subversion/libsvn_ra_serf/options.c	(working copy)
>>>>> @@ -245,7 +245,8 @@
>>>>>              (char *)svn_fspath__canonicalize(val, session->pool);
>>>>>            session->repos_root_str =
>>>>>              svn_urlpath__canonicalize(
>>>>> -                apr_uri_unparse(session->pool, &session->repos_root,
>>> 0),
>>>>> +                apr_uri_unparse(session->pool, &session->repos_root,
>>>>> +                                APR_URI_UNP_REVEALPASSWORD),
>>>>>                  session->pool);
>>>>>          }
>>>>>        else if (svn_cstring_casecmp(key,
>> SVN_DAV_ME_RESOURCE_HEADER)
>>>> == 0)
>>>> So is this considered to be a bug? Is there another workaround as using
>>>> --user --password?
>>> As far as I can tell we only really support a username in the url for
>>> svn+XXX:// urls. In some other cases we just passed 'the unsupported'
> url
>> to
>>> the lower layers and the neon library (our <= 1.7 default) completely
>>> ignored this, while serf (which we use as default since 1.8) tried to
> use it
>>> as the hostname.
>>>
>>> I would really recommend not using a username in the url this way... You
>>> just store the password unencrypted on your disk in a place where it
> isn't
>>> even really used.
>>>
>>> It also breaks using 'svn cp WC WC2' where WC and WC2 have a slightly
>>> different authentication id.
>>>
>>> And as Subversion doesn't actually use the username and password from
>> the
>>> url, they won't be updated if you ever want to change your password (or
>> use
>>> the working copy as a different user)
>>>
>>> 	Bert
>> We are using a apache reverse proxy in front of subversion. This apache
>> uses a Single Sign On module, which handles the authentication. So I
>> agree, that Subversion doesn't actually needs/uses the username and
>> password. Unfortunately I have no idea, how to remove the username and
>> password, as it seems not to be part of the ProxyPass directive.
>>
>> Is there any way to restore the previous behavior (ignore username and
>> password) in Subversion?
> I'm not sure what you are talking about here.
>
> Whether or not you are using some kind of proxy doesn't matter at all, as
> Subversion never passed the information to a server and never should start
> doing that as it would introduce an inconsistency.
>
> And the problem you describe is pure client side... the problem is caused by
> invoking commands on the clients with a username (and potentially a
> password) in the url.
>
>
> I really hope that your proxy server isn't able to just invoke commands on
> the individual client pc's as that would be a huge security problem in your
> setup.
>
>
> Our server protocol is completely described as relative to (and below) the
> BASE url of the repository, so we don't even process the hostname there.
>
> Some webbrowsers allowed passing user@ in their urls years ago and stopped
> for very good (security) reasons. We never supported this on urls except for
> the very specific svn+ssh://user@hostname/ cases where there is no other way
> to pass a user (and you might actually use a different user for the SSH part
> and the svnserve connection that we tunnel over it).
>
>
> The problem is that we accidentally accepted and ignored these parts in our
> URLs (because the libneon parse functions ignored it for us) and somehow
> your code started relying on that.
>
>
> As we rely on the repository root url being canonical, you are introducing
> problems for yourself by adding details there that will make working copies
> incompatible with clients that don't expect this.
>
> E.g.
> $ svn cp WC1/file WC2/file
>
> Will never work if WC1 and WC2 are from different repositories... and the
> way we check that is by comparing the repository root url and the UUID. If
> either is different you will get errors that the repository is not the same.
>
>
>
> The best thing I can think of is that we automatically redirect DAV
> repositories with a username in their url to the location without the
> username (as that would resolve the problem I just described for almost
> every user that accidentally uses this), but I'm guessing that this will
> break your use case even further.
>
>
> 	Bert
Thank you very much for that detailed explanation. Now I think we just
have to live the new behavior and fix our scripts accordingly.

Thanks again,
Guido

Mime
View raw message