Re: Implementing authenticated Smart HTTP - which URLs to secure

["Jonas H." <jonas@lophus.org>]

On 07/15/2012 10:49 PM, Shawn Pearce wrote:
> On Sun, Jul 15, 2012 at 6:43 AM, Jonas H. <jonas@lophus.org> 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