On Tue, Aug 30, 2011 at 10:38 PM, Jeff King <peff@xxxxxxxx> wrote:
[snip]
> It's "http:github.com", which has always looked a bit ugly to me. I had
> hoped they would just be opaque blobs and nobody would need to look at
> them. But when you get into things like setting the username via the
> config, then users see them, and they need to look sane. Making them
> look more like a canonicalized URL is probably a good thing.
A little feedback here: I do look into my keychain on Mac OS X. I
tend to keep most of my credentials in a separate keychain that gets
whenever my computer sleeps or the screen saver kicks on. So that
blob ends up being user-visible to some degree. Could I munge it into
something else? Sure. But I do wonder if it might be better to make
it something closer to what the user expects to see.
> After seeing the helper that Lukas posted recently on the list, I am
> wondering if they should include the username, too. I had left it
> separate, because I wanted helpers to be able to index "foo@xxxxxxxxxxx"
> and "example.com" in the same slot. I.e., to realize that the latter
> could use the same credentials cached for the former. But it also
> complicates the helpers; instead of doing:
Having the username separate is useful. At least under Mac OS X, the
"account name" field is a separate search field. It does make it
easier to fallback to just looking at the domain and path without
having to parse the unique token. But as it is, we stand a chance at
being able to reuse credentials already cached by the browser.
> credential = secure_storage_lookup(unique_token);
> return credential /* could be NULL */
>
> they have to do:
>
> for credential in secure_storage_lookup(unique_token) {
> if (!username)
> return credential; /* take first one arbitrarily */
> else if (username == credential.username)
> return credential; /* ok, matched preferred username */
> }
> return NULL;
>
> which implies that the secure storage can even store a list indexed
> under the token.
>
> So perhaps a better model is to give the helper some canonicalized URL,
> like:
>
> https://foo@xxxxxxxxxxx
>
> (where the canonicalization is important, because we want the helper to
> be able to just treat it like a string of bytes if it wants). And then
> we can naturally extend that to:
>
> https://foo@xxxxxxxxxxx/specific-repo.git
>
> if the user wants a repo-specific authentication context.
Or pass that the information via --domain and --path parameters. It'd
be nice to keep most credential backends from having to parse urls.
Not that its hard, just cumbersome. But the keychain implementation
and the gnome-keyring implementation could both benefit from having
the pieces broken out separately. Likewise, it's probably not
difficult to parse it out of the token if we needed to.
[snip good discussion]
One thing that crossed my mind while looking at this: what happens
when a command is meant to be non-interactive? Looking at the
kdewallet implementation, it appears that not only is the credential
helper intended to help do the lookup, but also ask the user for a
password, if it doesn't find anything. That doesn't seem like it
would play well in a non-interactive environment. Additionally, the
act of looking up the entry could pop up a dialog in most
keychain-like applications. Is there a need to be sensitive to the
fact that we may be run non-interactively?
-John
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html