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?
Thanks,
Guido
Received on 2014-04-08 12:19:33 CEST