{"thread":{"id":"31030","subject":"Implementing authenticated Smart HTTP - which URLs to secure","startedAt":"2012-07-15T13:43:15Z","lastAt":"2012-07-16T17:36:07Z","messageCount":3,"participants":["Jonas H.","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"195082","messageId":"5002C8F3.6080400@lophus.org","threadId":"31030","inReplyTo":null,"subject":"Implementing authenticated Smart HTTP - which URLs to secure","fromName":"Jonas H.","fromEmail":"jonas@lophus.org","sentAt":"2012-07-15T13:43:15Z","receivedAt":"2012-07-15T13:43:15Z","isPatch":false,"sender":{"key":"jonas@lophus.org","avatar":null},"body":"Howdy!\n\nI'd like to implement HTTP authentication for Git Smart HTTP using \nDulwich (a Python binding):\n\n1) read-only if unauthenticated and write only if authenticated\n2) read/write only if authenticated\n\nI couldn't find any documentation on which URLs need be secured and what \nresponse codes are expected in case the cloner/pusher is unauthenticated.\n\nIs there any documentation on Smart HTTP workflow?  The C sources \n(vanilla Git and libgit2) didn't help me too much since I found it very \ndifficult to follow the code-flow... it's probably just abstracted too \nwell :-)\n\nThanks!\nJonas\n"},{"id":"195086","messageId":"CAJo=hJv=h-+OsV2K_8VeEdrHoFem-Z7x+tkE7TXj5pNO5LAeow@mail.gmail.com","threadId":"31030","inReplyTo":"5002C8F3.6080400@lophus.org","subject":"Re: Implementing authenticated Smart HTTP - which URLs to secure","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-07-15T20:49:04Z","receivedAt":"2012-07-15T20:49:04Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Sun, Jul 15, 2012 at 6:43 AM, Jonas H. <jonas@lophus.org> wrote:\n> I'd like to implement HTTP authentication for Git Smart HTTP using Dulwich\n> (a Python binding):\n>\n> 1) read-only if unauthenticated and write only if authenticated\n> 2) read/write only if authenticated\n>\n> I couldn't find any documentation on which URLs need be secured and what\n> response codes are expected in case the cloner/pusher is unauthenticated.\n\nSmart HTTP uses HTTP authentication, so return 401 with a proper\nWWW-Authenticate header to prompt the client for authentication, and\nuse the Authorization header to verify the client. Return 403 to tell\nthe client they cannot access the service because the Authorization\nheader is invalid[1].\n\nYou can tell check for a write request by looking at the service\nparameter on the /info/refs request, if its git-receive-pack, you are\nabout to receive a write, so you want to prompt for authentication.\nYou should also check for authentication on the /git-receive-pack\nrequest.\n\n[1] This is actually a lie. The servers I have written over the years\nreturn 200 OK with a special Git payload in this case. The payload\nuses the \"ERR\" in the /info/refs response to print a message to the\nclient telling the user access is forbidden. This allows a custom\nmessage to be sent, and stops the client from discarding the message\nand falling back to the dumb protocol.\n\n> Is there any documentation on Smart HTTP workflow?  The C sources (vanilla\n> Git and libgit2) didn't help me too much since I found it very difficult to\n> follow the code-flow... it's probably just abstracted too well :-)\n\nThere is no authentication/authorization in the server components in\ngit-core. This is delegated to the web server that runs in front of\nGit, just like with the system SSH server handling authentication for\nGit over SSH.\n"},{"id":"195134","messageId":"50045107.1080608@lophus.org","threadId":"31030","inReplyTo":"CAJo=hJv=h-+OsV2K_8VeEdrHoFem-Z7x+tkE7TXj5pNO5LAeow@mail.gmail.com","subject":"Re: Implementing authenticated Smart HTTP - which URLs to secure","fromName":"Jonas H.","fromEmail":"jonas@lophus.org","sentAt":"2012-07-16T17:36:07Z","receivedAt":"2012-07-16T17:36:07Z","isPatch":false,"sender":{"key":"jonas@lophus.org","avatar":null},"body":"On 07/15/2012 10:49 PM, Shawn Pearce wrote:\n> On Sun, Jul 15, 2012 at 6:43 AM, Jonas H. <jonas@lophus.org> wrote:\n>> I'd like to implement HTTP authentication for Git Smart HTTP using Dulwich\n>> (a Python binding):\n>>\n>> 1) read-only if unauthenticated and write only if authenticated\n>> 2) read/write only if authenticated\n>>\n>> I couldn't find any documentation on which URLs need be secured and what\n>> response codes are expected in case the cloner/pusher is unauthenticated.\n>\n> Smart HTTP uses HTTP authentication, so return 401 with a proper\n> WWW-Authenticate header to prompt the client for authentication, and\n> use the Authorization header to verify the client. Return 403 to tell\n> the client they cannot access the service because the Authorization\n> header is invalid[1].\n>\n> You can tell check for a write request by looking at the service\n> parameter on the /info/refs request, if its git-receive-pack, you are\n> about to receive a write, so you want to prompt for authentication.\n> You should also check for authentication on the /git-receive-pack\n> request.\n\nThanks man! That helped a lot. I figured it has something to do with the \nargument to /info/refs but didn't make the connection between \"I want to \nupload\" and \"git-receive-pack\" -- it's pretty confusing that the \nargument is \"receive\" if I want to *upload*. At least when you don't \nknow the argument is the name of the service the client wants the server \nto start.\n\n> [1] This is actually a lie. The servers I have written over the years\n> return 200 OK with a special Git payload in this case. The payload\n> uses the \"ERR\" in the /info/refs response to print a message to the\n> client telling the user access is forbidden. This allows a custom\n> message to be sent, and stops the client from discarding the message\n> and falling back to the dumb protocol.\n\nI just experienced that exact problem. What worked for me is just \nkeeping responding with 401 Unauthorized.  Git will give up with a nice \nerror message (\"Authentication failed\") after a 2 or so tries.\n\nDo you know of any better way that does not require using the raw Git \nprotocol?\n\n> There is no authentication/authorization in the server components in\n> git-core. This is delegated to the web server that runs in front of\n> Git, just like with the system SSH server handling authentication for\n> Git over SSH.\n\nWell that explains why I couldn't find anything helpful in the code :-) \nThough I'm a bit confused by the lack of documentation on the subject \nsince I'm probably not the first one to set up a Git server with \nauthentication?!\n\nJonas\n"}]}