On 08.04.2014 13:30, Bert Huijben wrote: > >> -----Original Message----- >> From: Guido Wischrop [mailto:guido.wisch...@mgm-tp.com] >> Sent: dinsdag 8 april 2014 12:19 >> To: users@subversion.apache.org; d...@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.wisch...@mgm-tp.com] >>>> Sent: vrijdag 4 april 2014 15:07 >>>> To: users@subversion.apache.org; d...@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.wisch...@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
