From: Jonas H. Date: Mon, 16 Jul 2012 17:36:07 GMT Subject: Re: Implementing authenticated Smart HTTP - which URLs to secure Message-ID: <50045107.1080608@lophus.org> In-Reply-To: On 07/15/2012 10:49 PM, Shawn Pearce wrote: > On Sun, Jul 15, 2012 at 6:43 AM, Jonas H. wrote: >> I'd like to implement HTTP authentication for Git Smart HTTP using Dulwich >> (a Python binding): >> >> 1) read-only if unauthenticated and write only if authenticated >> 2) read/write only if authenticated >> >> I couldn't find any documentation on which URLs need be secured and what >> response codes are expected in case the cloner/pusher is unauthenticated. > > Smart HTTP uses HTTP authentication, so return 401 with a proper > WWW-Authenticate header to prompt the client for authentication, and > use the Authorization header to verify the client. Return 403 to tell > the client they cannot access the service because the Authorization > header is invalid[1]. > > You can tell check for a write request by looking at the service > parameter on the /info/refs request, if its git-receive-pack, you are > about to receive a write, so you want to prompt for authentication. > You should also check for authentication on the /git-receive-pack > request. Thanks man! That helped a lot. I figured it has something to do with the argument to /info/refs but didn't make the connection between "I want to upload" and "git-receive-pack" -- it's pretty confusing that the argument is "receive" if I want to *upload*. At least when you don't know the argument is the name of the service the client wants the server to start. > [1] This is actually a lie. The servers I have written over the years > return 200 OK with a special Git payload in this case. The payload > uses the "ERR" in the /info/refs response to print a message to the > client telling the user access is forbidden. This allows a custom > message to be sent, and stops the client from discarding the message > and falling back to the dumb protocol. I just experienced that exact problem. What worked for me is just keeping responding with 401 Unauthorized. Git will give up with a nice error message ("Authentication failed") after a 2 or so tries. Do you know of any better way that does not require using the raw Git protocol? > There is no authentication/authorization in the server components in > git-core. This is delegated to the web server that runs in front of > Git, just like with the system SSH server handling authentication for > Git over SSH. Well that explains why I couldn't find anything helpful in the code :-) Though I'm a bit confused by the lack of documentation on the subject since I'm probably not the first one to set up a Git server with authentication?! Jonas