git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).