On 08.04.2014 13:30, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Guido Wischrop [mailto:Guido.Wischrop_at_mgm-tp.com]
>> Sent: dinsdag 8 april 2014 12:19
>> To: users_at_subversion.apache.org; dev_at_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_at_mgm-tp.com]
>>>> Sent: vrijdag 4 april 2014 15:07
>>>> To: users_at_subversion.apache.org; dev_at_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_at_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_at_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
Received on 2014-04-08 13:52:54 CEST