From: Ted Zlatanov <tzz@lifelogs.com>
To: git@vger.kernel.org
Subject: credential helpers (was: What's cooking in git.git (Aug 2011, #07; Wed, 24))
Date: Fri, 26 Aug 2011 10:42:17 -0500 [thread overview]
Message-ID: <87aaawnpra.fsf_-_@lifelogs.com> (raw)
In-Reply-To: 7vhb55i11i.fsf@alter.siamese.dyndns.org
On Thu, 25 Aug 2011 15:22:49 -0700 Junio C Hamano <gitster@pobox.com> wrote:
JCH> We need to add "auth-domain" support, perhaps from the command line option
JCH> and configuration, if we ever need to support such a site.
JCH> We can consider what you already have as the default case for a more
JCH> general "we cut off at the hostname and take that as the auth-domain
JCH> boundary unless told otherwise". We may not have the way to "tell
JCH> otherwise" yet, but as long as we are reasonably confident that we know
JCH> how to extend the system in a backward compatible way, it is not a
JCH> show-stopper.
How about a config variable with regular expressions like
auth-domain.xyz.url = https://(.*@)?github.com/.*
so then accessing a remote with that URL with or without a username
would pass "auth-domain=xyz" to the helper? If there's no defined
auth-domain then it's not passed to the helper, so it has to just use
the host name (if there is an auth-domain the helper gets it PLUS the
hostname, of course).
I specify the "url" sub-key so we can add more auth-domain selection
criteria or other functionality in the future.
That gives the user a way to do, for instance:
auth-domain.internalcompany.url = https://.*.mycompany.com/.*
I also wanted to suggest that the credential helper should be able to
specify a SSL private user key and the passphrase for it for HTTPS
connections to servers that require such keys.
JCH> The primary reason why I wanted to hold this topic off was because of the
JCH> frequency of bug report we saw this round to topics _after_ they hit the
JCH> "master" branch, indicating that not many people are testing "next" during
JCH> the development cycle as they used to in olden days.
I'll be sure to test credential helpers next week.
Thank you
Ted
next prev parent reply other threads:[~2011-08-26 15:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-25 0:09 What's cooking in git.git (Aug 2011, #07; Wed, 24) Junio C Hamano
2011-08-25 7:43 ` Michael Haggerty
2011-08-25 20:20 ` Jeff King
2011-08-25 22:22 ` Junio C Hamano
2011-08-26 15:42 ` Ted Zlatanov [this message]
2011-08-31 2:20 ` Jeff King
2011-08-31 2:38 ` git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)] Jeff King
2011-09-09 9:55 ` John Szakmeister
2011-09-10 6:53 ` Jeff King
2011-09-13 8:29 ` John Szakmeister
2011-09-15 10:47 ` git credential helper design [ Ted Zlatanov
2011-08-25 21:50 ` What's cooking in git.git (Aug 2011, #07; Wed, 24) Heiko Voigt
2011-08-25 22:27 ` Junio C Hamano
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=87aaawnpra.fsf_-_@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=git@vger.kernel.org \
/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).