Re: Implementing authenticated Smart HTTP - which URLs to secure

From: Jonas H. <jonas@lophus.org>
Date: Jul 16, 2012, 17:36 UTC
Message-ID: <50045107.1080608@lophus.org>
In-Reply-To: <CAJo=hJv=h-+OsV2K_8VeEdrHoFem-Z7x+tkE7TXj5pNO5LAeow@mail.gmail.com>

On 07/15/2012 10:49 PM, Shawn Pearce wrote:

Show 21 quoted lines

> 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.

Show 6 quoted lines

> [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