Re: [PATCH 10/14] http: use hostname in credential description

Jeff King [off-list ref] writes:

It means that you can get convenient credential handling (whether it's
because you've configured a username, or you're getting it from a
wallet, or caching, or whatever) with:

  git push https://github.com/peff/git.git &&
  git push https://github.com/peff/foo.git

which should hopefully just prompt you once (and a configured username
would have to be configured only once for the host).

And it comes at the cost that there's not a good way to use two
different identities for the same host.

Yes, both "just prompt you once" and "would have to be configured only
once" cut both ways, and that is mildly disturbing to my taste.

If we annotate the remote in .git/config perhaps like this:

	[remote "foo"]
        	url = https://github.com/peff/foo.git
                auth_context = "foo project at github"
		...
	[remote "bar"]
        	url = https://github.com/peff/bar.git
                auth_context = "bar project at github"

and have "git push foo" pass the auth_context to the credential backend,
which can notice the two projects are in different context and cache two
identities under different contexts, would it be a good workaround for the
issue?  Then, a remote that does not have auth_context configured would
use "https:github.com" that is machine-generated (in http.c in your code),
but that can easily be overridden if/as necessary.

I tried to optimize for the common case (many repos under one identity)
than the uncommon (many identities under one host).

As I am not convinced if this statement is true.

On Fri, Jul 22, 2011 at 03:01:53PM -0700, Junio C Hamano wrote:

Yes, both "just prompt you once" and "would have to be configured only
once" cut both ways, and that is mildly disturbing to my taste.

If we annotate the remote in .git/config perhaps like this:

	[remote "foo"]
        	url = https://github.com/peff/foo.git
                auth_context = "foo project at github"
		...
	[remote "bar"]
        	url = https://github.com/peff/bar.git
                auth_context = "bar project at github"

and have "git push foo" pass the auth_context to the credential backend,
which can notice the two projects are in different context and cache two
identities under different contexts, would it be a good workaround for the
issue?  Then, a remote that does not have auth_context configured would
use "https:github.com" that is machine-generated (in http.c in your code),
but that can easily be overridden if/as necessary.

That has the minor downside of not handling one-off URLs.

Actually, though, I think even with the current code, you can do better
than that. The "username" is an implicit part of the context, as well. A
poorly-written helper might ignore it, of course, but you can already
say:

  [remote "foo"]
    url = https://peff@github.com/peff/foo.git
    ...
  [remote "bar"]
    url = https://otheruser@github.com/otheruser/foo.git"
    ...

The "cache" helper will match the username when looking up only a
password. The "store" helper is less exacting, and uses only the
opaque context. Mostly because it uses the config format as a backing
store, which makes pairing usernames and passwords more difficult (but
not impossible; it can be worked around by saving some context between
invocations of the config callback). So that's a good reason to improve
"store".

As a bonus, this technique actually works to access the exact same repo
as two different identities (whereas just including the path in the
context does not). E.g.:

  [remote "repo-as-me"]
    url = https://me@example.com/repo.git
    ...
  [remote "repo-as-other-role"]
    url = https://role@example.com/repo.git
    ...

I expect those cases to be even less common, of course, but it's nice
that it's straightforward to support them.

quoted

I tried to optimize for the common case (many repos under one identity)
than the uncommon (many identities under one host).

As I am not convinced if this statement is true.

I admit I don't have any data beyond my own experiences. GitHub tends
towards the concept of a single identity, and it has some group
management. I don't know about other sites, though. Do you have any
specific examples in mind?

-Peff

On Fri, 22 Jul 2011 16:13:38 -0600 Jeff King [off-list ref] wrote: 

JK> I admit I don't have any data beyond my own experiences. GitHub tends
JK> towards the concept of a single identity, and it has some group
JK> management. I don't know about other sites, though. Do you have any
JK> specific examples in mind?

I have not yet needed multiple user names on a single Git server, so I
think it's OK to make that case less convenient to favor the more common
single user name case.

Ted

I see some info in "What's Cooking" about this patch but it's unclear to
me whether the hostname issue (where it's hard to have multiple
identities on a single server, which I think is all right) is blocking
the inclusion of the patch into the next release, or if it will be
included eventually if no one complains about that issue, or something
else...

Thanks
Ted

On Fri, Aug 19, 2011 at 07:01:21AM -0500, Ted Zlatanov wrote:

I see some info in "What's Cooking" about this patch but it's unclear to
me whether the hostname issue (where it's hard to have multiple
identities on a single server, which I think is all right) is blocking
the inclusion of the patch into the next release, or if it will be
included eventually if no one complains about that issue, or something
else...

Junio and I discussed it a bit in another thread. I think the ability to
use "user@hostname" to disambiguate means the problem is dealt with at a
high level. And the "cache" helper handles that just fine. But the
"store" helper will conflate two entries for the same host. I'll see if
I can work on a patch for that.

It looks like Junio is planning to hold the series off until 1.7.8. Have
you been working on a Secrets API helper? If so, I'd love to get
feedback on how well the interface is serving your needs.

-Peff

On Thu, 25 Aug 2011 16:23:26 -0400 Jeff King [off-list ref] wrote: 

JK> On Fri, Aug 19, 2011 at 07:01:21AM -0500, Ted Zlatanov wrote:

quoted

I see some info in "What's Cooking" about this patch but it's unclear to
me whether the hostname issue (where it's hard to have multiple
identities on a single server, which I think is all right) is blocking
the inclusion of the patch into the next release, or if it will be
included eventually if no one complains about that issue, or something
else...

JK> Junio and I discussed it a bit in another thread. I think the ability to
JK> use "user@hostname" to disambiguate means the problem is dealt with at a
JK> high level. And the "cache" helper handles that just fine. But the
JK> "store" helper will conflate two entries for the same host. I'll see if
JK> I can work on a patch for that.

Cool, I hope this is the last wrinkle on the bundled helpers.

JK> It looks like Junio is planning to hold the series off until 1.7.8. Have
JK> you been working on a Secrets API helper? If so, I'd love to get
JK> feedback on how well the interface is serving your needs.

Work and Real Life have interfered with coding for fun, but I will have
time next week to try writing a few helpers.  This is high priority for
me because of various projects that require it; sorry for taking so long
to start using it.

Ted