summaryrefslogtreecommitdiff
path: root/t/t9115
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2011-12-10 05:31:21 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2011-12-11 23:16:24 -0800
commit148bb6a7b4d82a6380c6a51951b870933564c115 (patch)
tree7f3fe742ffcff886cb92cceff93d7de94dc93046 /t/t9115
parentcredential: add function for parsing url components (diff)
downloadtgif-148bb6a7b4d82a6380c6a51951b870933564c115.tar.xz
http: use credential API to get passwords
This patch converts the http code to use the new credential API, both for http authentication as well as for getting certificate passwords. Most of the code change is simply variable naming (the passwords are now contained inside the credential struct) or deletion of obsolete code (the credential code handles URL parsing and prompting for us). The behavior should be the same, with one exception: the credential code will prompt with a description based on the credential components. Therefore, the old prompt of: Username for 'example.com': Password for 'example.com': now looks like: Username for 'https://example.com/repo.git': Password for 'https://user@example.com/repo.git': Note that we include more information in each line, specifically: 1. We now include the protocol. While more noisy, this is an important part of knowing what you are accessing (especially if you care about http vs https). 2. We include the username in the password prompt. This is not a big deal when you have just been prompted for it, but the username may also come from the remote's URL (and after future patches, from configuration or credential helpers). In that case, it's a nice reminder of the user for which you're giving the password. 3. We include the path component of the URL. In many cases, the user won't care about this and it's simply noise (i.e., they'll use the same credential for a whole site). However, that is part of a larger question, which is whether path components should be part of credential context, both for prompting and for lookup by storage helpers. That issue will be addressed as a whole in a future patch. Similarly, for unlocking certificates, we used to say: Certificate Password for 'example.com': and we now say: Password for 'cert:///path/to/certificate': Showing the path to the client certificate makes more sense, as that is what you are unlocking, not "example.com". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t9115')
0 files changed, 0 insertions, 0 deletions