From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 10/14] http: use hostname in credential description
Date: Fri, 22 Jul 2011 16:13:38 -0600 [thread overview]
Message-ID: <20110722221337.GA15753@sigill.intra.peff.net> (raw)
In-Reply-To: <7vbowmx9da.fsf@alter.siamese.dyndns.org>
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.
> > 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
next prev parent reply other threads:[~2011-07-22 22:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 7:46 [RFC/PATCH 0/14] less annoying http authentication Jeff King
2011-07-18 7:48 ` [PATCH 01/14] parse-options: add OPT_STRING_LIST helper Jeff King
2011-07-18 7:48 ` [PATCH 02/14] url: decode buffers that are not NUL-terminated Jeff King
2011-07-20 22:16 ` Junio C Hamano
2011-07-18 7:49 ` [PATCH 03/14] improve httpd auth tests Jeff King
2011-07-18 7:49 ` [PATCH 04/14] remote-curl: don't retry auth failures with dumb protocol Jeff King
2011-07-18 7:50 ` [PATCH 05/14] http: retry authentication failures for all http requests Jeff King
2011-07-18 7:50 ` [PATCH 06/14] introduce credentials API Jeff King
2011-07-20 22:17 ` Junio C Hamano
2011-07-22 20:39 ` Jeff King
2011-07-22 21:42 ` Junio C Hamano
2011-07-22 22:16 ` Jeff King
2011-07-21 21:59 ` Junio C Hamano
2011-07-22 20:40 ` Jeff King
2011-07-18 7:50 ` [PATCH 07/14] http: use credential API to get passwords Jeff King
2011-07-18 7:51 ` [PATCH 08/14] look for credentials in config before prompting Jeff King
2011-07-18 7:51 ` [PATCH 09/14] allow the user to configure credential helpers Jeff King
2011-07-18 7:52 ` [PATCH 10/14] http: use hostname in credential description Jeff King
2011-07-20 22:17 ` Junio C Hamano
2011-07-22 20:47 ` Jeff King
2011-07-22 22:01 ` Junio C Hamano
2011-07-22 22:13 ` Jeff King [this message]
2011-08-08 14:37 ` Ted Zlatanov
2011-08-08 17:16 ` Junio C Hamano
2011-08-19 12:01 ` Ted Zlatanov
2011-08-25 20:23 ` Jeff King
2011-08-26 15:29 ` Ted Zlatanov
2011-07-18 7:52 ` [PATCH 11/14] docs: end-user documentation for the credential subsystem Jeff King
2011-07-20 22:17 ` Junio C Hamano
2011-07-18 7:55 ` [PATCH 12/14] credentials: add "cache" helper Jeff King
2011-07-18 7:58 ` [PATCH 13/14] credentials: add "store" helper Jeff King
2011-07-18 7:58 ` [PATCH 14/14] credentials: add "getpass" helper Jeff King
2011-07-18 8:00 ` [RFC/PATCH 0/14] less annoying http authentication Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110722221337.GA15753@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).