On Thu, Aug 25, 2011 at 03:22:49PM -0700, Junio C Hamano wrote: > > I'm OK with holding this off for another round. I'd really like to get > > more feedback from third-party helper writers. ... > > I actually do not think the lack of finer-than-host level granularity a > problem we need to solve before moving forward. IIRC, when accessing > "http://github.com/frotz"; and "http://github.com/nitfol";, you would key > the authentication material with something like "http://github.com"; (or > was it "http:github.com"? the details do not matter for the purpose of > this discussion). 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. 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: 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. > We can consider what you already have as the default case for a more > general "we cut off at the hostname and take that as the auth-domain > boundary unless told otherwise". We may not have the way to "tell > otherwise" yet, but as long as we are reasonably confident that we know > how to extend the system in a backward compatible way, it is not a > show-stopper. I think in either case it gets tacked onto the auth token. But it probably makes sense now to choose a nice syntax for the token that will look good when we extend it later. Ted wrote: > How about a config variable with regular expressions like > > auth-domain.xyz.url = https://(.*@)?github.com/.* I like this. In fact, perhaps it makes sense for git to generate the maximal token, like: https://user@xxxxxxxxxxxxxxxx/path/to/repo.git and then provide the user with configuration like this to narrow it down as they see fit. Perhaps even do a substitution regexp to let them rewrite it arbitrarily. And then if we want to be more permissive by default, provide some backup regexps to be used when they don't provide their own, like cutting out the pathname portion. -Peff -- 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