Re: Implementing authenticated Smart HTTP - which URLs to secure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/15/2012 10:49 PM, Shawn Pearce wrote:
On Sun, Jul 15, 2012 at 6:43 AM, Jonas H. <jonas@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]