diff options
author | Jeff King <peff@peff.net> | 2013-04-10 23:32:11 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2013-04-11 07:33:07 -0700 |
commit | fdae191003381b1e2026422ffbd580ba39f1ab91 (patch) | |
tree | 8e980690cba65b095b73f43dc0cea5bc7964401b | |
parent | Git 1.8.2.1 (diff) | |
download | tgif-fdae191003381b1e2026422ffbd580ba39f1ab91.tar.xz |
doc/http-backend: clarify "half-auth" repo configuration
When the http-backend is set up to allow anonymous read but
authenticated write, the http-backend manual suggests
catching only the "/git-receive-pack" POST of the packfile,
not the initial "info/refs?service=git-receive-pack" GET in
which we advertise refs.
This does work and is secure, as we do not allow any write
during the info/refs request, and the information in the ref
advertisement is the same that you would get from a fetch.
However, the configuration required by the server is
slightly more complex. The default `http.receivepack`
setting is to allow pushes if the webserver tells us that
the user authenticated, and otherwise to return a 403
("Forbidden"). That works fine if authentication is turned
on completely; the initial request requires authentication,
and http-backend realizes it is OK to do a push.
But for this "half-auth" state, no authentication has
occurred during the initial ref advertisement. The
http-backend CGI therefore does not think that pushing
should be enabled, and responds with a 403. The client
cannot continue, even though the server would have allowed
it to run if it had provided credentials.
It would be much better if the server responded with a 401,
asking for credentials during the initial contact. But
git-http-backend does not know about the server's auth
configuration (so a 401 would be confusing in the case of a
true anonymous server). Unfortunately, configuring Apache to
recognize the query string and apply the auth appropriately
to receive-pack (but not upload-pack) initial requests is
non-trivial.
The site admin can work around this by just turning on
http.receivepack explicitly in its repositories. Let's
document this workaround.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
-rw-r--r-- | Documentation/git-http-backend.txt | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt index 7b1e85cd15..f43980ff9c 100644 --- a/Documentation/git-http-backend.txt +++ b/Documentation/git-http-backend.txt @@ -91,6 +91,15 @@ require authorization with a LocationMatch directive: </LocationMatch> ---------------------------------------------------------------- + +In this mode, the server will not request authentication until the +client actually starts the object negotiation phase of the push, rather +than during the initial contact. For this reason, you must also enable +the `http.receivepack` config option in any repositories that should +accept a push. The default behavior, if `http.receivepack` is not set, +is to reject any pushes by unauthenticated users; the initial request +will therefore report `403 Forbidden` to the client, without even giving +an opportunity for authentication. ++ To require authentication for both reads and writes, use a Location directive around the repository, or one of its parent directories: + |