aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/git-http-backend.txt
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2013-04-10 23:32:11 -0400
committerJunio C Hamano <gitster@pobox.com>2013-04-11 07:33:07 -0700
commitfdae191003381b1e2026422ffbd580ba39f1ab91 (patch)
tree8e980690cba65b095b73f43dc0cea5bc7964401b /Documentation/git-http-backend.txt
parent5bda18c186e455f8e65f976d3bf333ab1f4b5b53 (diff)
downloadgit-fdae191003381b1e2026422ffbd580ba39f1ab91.tar.gz
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>
Diffstat (limited to 'Documentation/git-http-backend.txt')
-rw-r--r--Documentation/git-http-backend.txt9
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:
+