Re: git no longer prompting for password
- From
Jeff King <peff@peff.net>
- Date
- Aug 25, 2012, 20:39 UTC
- Message-ID
- <20120825203904.GA10470@sigill.intra.peff.net>
- In-Reply-To
- <5038E781.1090008@gmail.com>
On Sat, Aug 25, 2012 at 03:56:01PM +0100, Iain Paton wrote:
Show 7 quoted lines
> > It's like the initial http requests do not get a 401, and the push > > proceeds, and then some later request causes a 401 when we do not expect > > it. Which is doubly odd, since we should also be able to handle that > > case (the first 401 we get should cause us to ask for a password). > > Yes, I deliberately have it set for anonymous pull and authenticated push. > So the initial contact with the server doesn't ask for auth.
OK, I see what's going on. It looks like it is configured to do so by rejecting the POST request. So this first request works:
Show 7 quoted lines
> > GET /git/test.git/info/refs?service=git-receive-pack HTTP/1.1 > User-Agent: git/1.7.8 > Host: 10.44.16.74 > Accept: */* > Pragma: no-cache > > < HTTP/1.1 200 OK
which is the first step of the conversation, in which the client gets the set of refs from the remote. Then it tries to POST the pack:
Show 10 quoted lines
> > POST /git/test.git/git-receive-pack HTTP/1.1 > User-Agent: git/1.7.8 > Host: 10.44.16.74 > Accept-Encoding: deflate, gzip > Content-Type: application/x-git-receive-pack-request > Accept: application/x-git-receive-pack-result > Content-Length: 412 > > * upload completely sent off: 412 out of 412 bytes > < HTTP/1.1 401 Unauthorized
And we get blocked on that request. I didn't quote it above, but note how the client actually generates and sends the full pack before being told "no, you can't do this".
So that explains the output you see; we really are generating and sending the pack, and only then getting a 401. And it also explains why git does not prompt and retry; we follow a different code path for POSTs that does not trigger the retry code.
This is not optimal, as we send the pack data only to find out that we are not authenticated. There is code to avoid sending the _whole_ pack (it's the probe_rpc code in remote-curl.c), so I think you'd just be wasting 64K, which is not too bad. So we could teach git to retry if the POST fails, and I think it would work OK.
But I don't think there is any reason not to block the push request right from the first receive-pack request we see, which catches the issue even earlier, and with less overhead (and of course works with existing git clients :) ).
Show 13 quoted lines
> apache config has the following: > [...] > <LocationMatch "^/git/.*/git-receive-pack$"> > AuthType Basic > AuthUserFile /data/git/htpasswd > AuthGroupfile /data/git/groups > AuthName "Git Access" > > Require group committers > </LocationMatch> > > nothing untoward there I think and google turns up lots of examples where > people are doing essentially the same thing.
I think your regex is the culprit. The first request comes in with:
> > GET /git/test.git/info/refs?service=git-receive-pack HTTP/1.1
The odd URL is because we are probing to see if the server even supports smart-http. But note that it does not match your regex above, which requires "/git-receive-pack". It looks like that is pulled straight from the git-http-backend manpage. I think the change in v1.7.8 broke people using that configuration.
I tend to think the right thing is to fix the configuration (both on your system and in the documentation), but we should probably also fix git to handle this situation more gracefully, since it used to work and has been advertised in the documentation for a long time.
-Peff