> -----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
>
> Thanks,
> Guido
Received on 2014-04-08 13:31:27 CEST