You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by pe...@bigfoot.com on 2009/04/07 22:10:22 UTC
Using http:// URL that contains a username
Does SVN support the use of a username within an https:// URL?
In other words, say I'm logged into a workstation with the username "bozo"
and I run the following command:
$ svn info svn+ssh://bclown@svn.example.com/repo
It works fine. I can contact the SVN server as "bclown", which is my
username on that server. But, if I try to contact the server using
https:// instead of svn+ssh://...
$ svn info https://bclown@svn.example.com/repo
I get prompted for the password for user "bozo"... NOT user "bclown", eg:
$ svn info https://bclown@svn.example.com/repo
Authentication realm: <https://svn.example.com:443> Example Repo
Password for 'bozo':
I realize I can use the --username option, but --username doesn't work
with svn+ssh://, which means I need to use 2 different methods to specify
the username.
Is there a particular reason svn doesn't support a username as part of the
URL with https:// or is there something wrong with my Apache setup which
is preventing it from working?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1584520
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Using http:// URL that contains a username
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, jhanley@dgtlrift.com!
>>>> For different copies and purposes, may be. But still, I would stick to one
>>>> way or another, reusing SVN auth cache as much as possible without
>>>> unnecessary
>>>> bloating.
>>
>>> It's not bloating, its implementing section 3.2.1 of RFC 3986
>>
>> You messing things.
>> Bloating in my sentence was in reference to the way SVN storing auth cache.
>> For svn://host and https://host it'll be two different entries in database.
> Ahh, Yes. I see and agree - this example would clutter up the cred db,
> but I believe the original author was just using the two URLs to the
> same server for illustration purposes tto show that there is a
> difference in operation. I don't picture individual users accessing
> the same server by different protocol means.
> You bring up a point & question that is beyond the scope of this
> thread - would every protocol to the same resource generate additional
> entries to the db? ie http, https, svn, svn+ssh, file, future
> protocols? Additionally, what about hostname vs fqdn? ie would
> http://oursvnserver/ vs http://oursvnserver.ourcompany.com/ generate
> multiple entries?
Right. Ok.
My only thought is that if any change could be done in this regard, the auth
creds could be bound to repository UUID.
Not explicitly universal scheme, but i see very few operations where the UUID
couldn't known in advance.
For that matter, it would be probably worth storing all used access methods in
the cache file and if we need to authorize for export (one of possible
examples), and repository asking us for authentication before providing UUID,
we could try the URL math first, then ask user if none matched or one we tried
was rejected.
Like this example (completely hand-made for illustrative purposes only)
> K 15
> svn:UUID
> V 36
> f4de985e-6dcf-9f4d-8c76-0c4191c3a480
> K 8
> passtype
> V 8
> wincrypt
> K 8
> password
> V ***
> hereitis
> K 15
> svn:repositoryroot
> V 37 35 36 38
> https://svn.example.com:443/svn/repos
> http://svn.example.com:80/svn/repos
> svn://svn.example.com:port/svn/repos
> svn+ssh://svn.example.com:22/svn/repos
> K 8
> username
> V 9
> AnrDaemon
> END
Sidenote.
I've found that SVN storing auth cache per-realm
i.e.
svn:realmstring
V 48
<http://svn.example.com:80> Subversion repository
But it is likely that for different repositories on the same realm you could
be using different names.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 08.04.2009, <17:51>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1596957
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Using http:// URL that contains a username
Posted by Jim Hanley <jh...@DGtlRift.com>.
Quoting Andrey Repin <an...@freemail.ru>:
> Greetings, jhanley@dgtlrift.com!
>
>>> For different copies and purposes, may be. But still, I would stick to one
>>> way or another, reusing SVN auth cache as much as possible without
>>> unnecessary
>>> bloating.
>
>> It's not bloating, its implementing section 3.2.1 of RFC 3986
>
> You messing things.
> Bloating in my sentence was in reference to the way SVN storing auth cache.
> For svn://host and https://host it'll be two different entries in database.
Ahh, Yes. I see and agree - this example would clutter up the cred db,
but I believe the original author was just using the two URLs to the
same server for illustration purposes tto show that there is a
difference in operation. I don't picture individual users accessing
the same server by different protocol means.
You bring up a point & question that is beyond the scope of this
thread - would every protocol to the same resource generate additional
entries to the db? ie http, https, svn, svn+ssh, file, future
protocols? Additionally, what about hostname vs fqdn? ie would
http://oursvnserver/ vs http://oursvnserver.ourcompany.com/ generate
multiple entries?
-Jim
Re: Using http:// URL that contains a username
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, jhanley@dgtlrift.com!
>> For different copies and purposes, may be. But still, I would stick to one
>> way or another, reusing SVN auth cache as much as possible without
>> unnecessary
>> bloating.
> It's not bloating, its implementing section 3.2.1 of RFC 3986
You messing things.
Bloating in my sentence was in reference to the way SVN storing auth cache.
For svn://host and https://host it'll be two different entries in database.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 08.04.2009, <17:03>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1596236
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Using http:// URL that contains a username
Posted by Jim Hanley <jh...@DGtlRift.com>.
Quoting Andrey Repin <an...@freemail.ru>:
> Greetings, Ryan Schmidt!
>
>>> Better stick to one way of accessing SVN on single host, unless
>>> there's
>>> something special about it.
>
>> Why? Using multiple access methods for a single repository is
>> allowed, and even described in the book. Yes, it's more work to set
>> up correctly and there are some issues to be aware of, but it
>> shouldn't be prohibited outright.
>
>> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.multimethod.html
>
> I shall point to "from same [client] host" in my sentence once again.
> I can't imagine efficient scheme in which I could use both svn://
> and https://
> from my working PC at the same time for the same working copy.
The example the originating author used is /not/ a working copy, but a
URL. The argument against supporting such common standard
functionality is invalid considering that /every/ browser allows the
use of http(s)://user:pass@server/ for authenticated realms.
> For different copies and purposes, may be. But still, I would stick to one
> way or another, reusing SVN auth cache as much as possible without
> unnecessary
> bloating.
It's not bloating, its implementing section 3.2.1 of RFC 3986
> However, it is likely to be demanded and used feature if Subversion could
> take username from URL.
> At the very least, it'll make --username redundant as well as allow users to
> completely disable credentials storing and still be able to only type the
> password, because username already supplied (and stored if it is WC) as part
> of repository path.
> But there's a necessary precaution: user could take a step further and supply
> password in URL. This password should never be stored in WC. Taken in count,
> may be, stored in auth cache, may be, but not in WC, in clear text.
>
> P.S.
> Using my shared hosting shell... SVN 1.4.3 on FreeBSD >.< storing
> passwords in
> clear text in auth cache. Not enjoyable... would it change if they
> upgrade SVN
> to 1.5 or 1.6 ?
>
>
> --
> WBR,
> Andrey Repin (anrdaemon@freemail.ru) 08.04.2009, <15:10>
>
> Sorry for my terrible english...
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1595196
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@subversion.tigris.org].
>
Re: Using http:// URL that contains a username
Posted by Greg Troxel <gd...@ir.bbn.com>.
Ryan Schmidt <su...@ryandesign.com> writes:
> In 1.6, you can store the passwords in GNOME Keyring or KWallet, so
> if you have one of those services available to you on your client,
> then yes, upgrading to 1.6 would help.
>
> http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-
> improvements
Interesting - I wonder if the bug on OS X where
svn merge --non-interactive
always fails is fixed or now affects gnome keychain. This is keeping me
Re: Using http:// URL that contains a username
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 8, 2009, at 06:36, Andrey Repin wrote:
> Using my shared hosting shell... SVN 1.4.3 on FreeBSD >.< storing
> passwords in
> clear text in auth cache. Not enjoyable... would it change if they
> upgrade SVN
> to 1.5 or 1.6 ?
In 1.6, you can store the passwords in GNOME Keyring or KWallet, so
if you have one of those services available to you on your client,
then yes, upgrading to 1.6 would help.
http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-
improvements
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1595356
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Using http:// URL that contains a username
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Ryan Schmidt!
>> Better stick to one way of accessing SVN on single host, unless
>> there's
>> something special about it.
> Why? Using multiple access methods for a single repository is
> allowed, and even described in the book. Yes, it's more work to set
> up correctly and there are some issues to be aware of, but it
> shouldn't be prohibited outright.
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.multimethod.html
I shall point to "from same [client] host" in my sentence once again.
I can't imagine efficient scheme in which I could use both svn:// and https://
from my working PC at the same time for the same working copy.
For different copies and purposes, may be. But still, I would stick to one
way or another, reusing SVN auth cache as much as possible without unnecessary
bloating.
It is not a question to the server setup.
However, it is likely to be demanded and used feature if Subversion could
take username from URL.
At the very least, it'll make --username redundant as well as allow users to
completely disable credentials storing and still be able to only type the
password, because username already supplied (and stored if it is WC) as part
of repository path.
But there's a necessary precaution: user could take a step further and supply
password in URL. This password should never be stored in WC. Taken in count,
may be, stored in auth cache, may be, but not in WC, in clear text.
P.S.
Using my shared hosting shell... SVN 1.4.3 on FreeBSD >.< storing passwords in
clear text in auth cache. Not enjoyable... would it change if they upgrade SVN
to 1.5 or 1.6 ?
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 08.04.2009, <15:10>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1595196
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Using http:// URL that contains a username
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 7, 2009, at 20:00, Andrey Repin wrote:
> Greetings, petesea@bigfoot.com!
>
>> Does SVN support the use of a username within an https:// URL?
>
>> In other words, say I'm logged into a workstation with the
>> username "bozo"
>> and I run the following command:
>
>> $ svn info svn+ssh://bclown@svn.example.com/repo
>
> It is not SVN, it is SSH works with username suppled in URL.
It's not an unreasonable request though. Web browsers work with
usernames inside the http/https URL too.
>> It works fine. I can contact the SVN server as "bclown", which is my
>> username on that server. But, if I try to contact the server using
>> https:// instead of svn+ssh://...
>
>> $ svn info https://bclown@svn.example.com/repo
>
>> I get prompted for the password for user "bozo"... NOT user
>> "bclown", eg:
>
>> $ svn info https://bclown@svn.example.com/repo
>> Authentication realm: <https://svn.example.com:443> Example Repo
>> Password for 'bozo':
>
>> I realize I can use the --username option, but --username doesn't
>> work
>> with svn+ssh://, which means I need to use 2 different methods to
>> specify
>> the username.
>
>> Is there a particular reason svn doesn't support a username as
>> part of the
>> URL with https:// or is there something wrong with my Apache setup
>> which
>> is preventing it from working?
>
> Better stick to one way of accessing SVN on single host, unless
> there's
> something special about it.
Why? Using multiple access methods for a single repository is
allowed, and even described in the book. Yes, it's more work to set
up correctly and there are some issues to be aware of, but it
shouldn't be prohibited outright.
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.multimethod.html
> As I said, it's not SVN working with URL when you connecting
> through SSH.
> When SVN doing authorization by itself, it storing credentials in
> user area,
> so you do not need to enter username next time you accessing the same
> repository.
> You should really read svnbook, I do not have time to retype whole
> chapters
> from it in a single message.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1589366
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Using http:// URL that contains a username
Posted by pe...@bigfoot.com.
On Wed, 8 Apr 2009, Andrey Repin wrote:
> Greetings, petesea@bigfoot.com!
>
>> Does SVN support the use of a username within an https:// URL?
>
>> In other words, say I'm logged into a workstation with the username
>> "bozo" and I run the following command:
>
>> $ svn info svn+ssh://bclown@svn.example.com/repo
>
> It is not SVN, it is SSH works with username suppled in URL.
Sorry... I guess I should have been clearer. I realize in the case of
svn+ssh://, SSH is the one parsing the username from the URL. I was
simply using it as an example of an URL that works with an embedded
username.
>> It works fine. I can contact the SVN server as "bclown", which is my
>> username on that server. But, if I try to contact the server using
>> https:// instead of svn+ssh://...
>
>> $ svn info https://bclown@svn.example.com/repo
>
>> I get prompted for the password for user "bozo"... NOT user "bclown", eg:
>
>> $ svn info https://bclown@svn.example.com/repo
>> Authentication realm: <https://svn.example.com:443> Example Repo
>> Password for 'bozo':
>
>> I realize I can use the --username option, but --username doesn't work
>> with svn+ssh://, which means I need to use 2 different methods to specify
>> the username.
>
>> Is there a particular reason svn doesn't support a username as part of
>> the URL with https:// or is there something wrong with my Apache setup
>> which is preventing it from working?
At the time I asked, I wasn't sure if SVN supported this syntax or not...
in other words, I wasn't sure if I was doing something wrong either on the
client or server that prevented a username in an https:// URL from
working. From the sounds of it, it appears that's not the case and SVN
simply doesn't support it.
So, let me rephrase the question...
Is there a specific reason SVN doesn't support a username as part of an
https:// URL? The syntax for an URL has included an optional username for
quite some time... since the beginning I believe and at least long before
SVN. So it makes me wonder why it isn't supported by SVN?
> Better stick to one way of accessing SVN on single host, unless there's
> something special about it.
I do have reasons for needing both methods.
> As I said, it's not SVN working with URL when you connecting through
> SSH. When SVN doing authorization by itself, it storing credentials in
> user area, so you do not need to enter username next time you accessing
> the same repository.
>
> You should really read svnbook, I do not have time to retype whole
> chapters from it in a single message.
I'll admit, I have not read every word of the Subversion book, but I have
read the relevant sections on this subject and searched the entire book
for keywords relating to this subject. If you know of a particular
section that explicitly says a username as part of the URL is or is NOT
supported and/or why it's not supported I'd love to know about it. I
understand you are very busy, so won't ask you to retype any applicable
sections, a link to the section would be nice though.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1599214
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Using http:// URL that contains a username
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, petesea@bigfoot.com!
> Does SVN support the use of a username within an https:// URL?
> In other words, say I'm logged into a workstation with the username "bozo"
> and I run the following command:
> $ svn info svn+ssh://bclown@svn.example.com/repo
It is not SVN, it is SSH works with username suppled in URL.
> It works fine. I can contact the SVN server as "bclown", which is my
> username on that server. But, if I try to contact the server using
> https:// instead of svn+ssh://...
> $ svn info https://bclown@svn.example.com/repo
> I get prompted for the password for user "bozo"... NOT user "bclown", eg:
> $ svn info https://bclown@svn.example.com/repo
> Authentication realm: <https://svn.example.com:443> Example Repo
> Password for 'bozo':
> I realize I can use the --username option, but --username doesn't work
> with svn+ssh://, which means I need to use 2 different methods to specify
> the username.
> Is there a particular reason svn doesn't support a username as part of the
> URL with https:// or is there something wrong with my Apache setup which
> is preventing it from working?
Better stick to one way of accessing SVN on single host, unless there's
something special about it.
As I said, it's not SVN working with URL when you connecting through SSH.
When SVN doing authorization by itself, it storing credentials in user area,
so you do not need to enter username next time you accessing the same
repository.
You should really read svnbook, I do not have time to retype whole chapters
from it in a single message.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 08.04.2009, <4:55>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1587264
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].