{"thread":{"id":"38264","subject":"bearer token authorization with HTTPS transport","startedAt":"2014-12-30T19:24:09Z","lastAt":"2015-01-06T16:37:29Z","messageCount":6,"participants":["David Renshaw","brian m. carlson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"254209","messageId":"CACejzECGUnH6B2Leq+H6u0Joo1SQmMCZ5UoHja_fK99+6a_iEA@mail.gmail.com","threadId":"38264","inReplyTo":null,"subject":"bearer token authorization with HTTPS transport","fromName":"David Renshaw","fromEmail":"david@sandstorm.io","sentAt":"2014-12-30T19:24:09Z","receivedAt":"2014-12-30T19:24:09Z","isPatch":false,"sender":{"key":"david@sandstorm.io","avatar":null},"body":"Hi,\nI would like to be able to serve a git repository over HTTPS from a\nweb server that requires OAuth2-style bearer tokens for authorization.\nFor more context, see this thread:\nhttps://groups.google.com/forum/#!topic/sandstorm-dev/4oigfb4-9E4\n\nDoes anyone here have any advice about how to convince a git client to\nadd an \"Authorization: Bearer \" header?\n\nI can think of a few approaches:\n\n(1) I could modify the curl remote helper to insert the header if it\nsees a \"bearertoken\" config option. I have in fact written a\nproof-of-concept patch that does this (see\nhttps://github.com/dwrensha/git/commit/4da7b64b85b3b6652abe7), but I\ndon't know how much of chance something like this has of getting\nmerged into the mainline git client.\n\n(2) I could write a new remote helper for, say, a \"https+bearertoken\"\ntransport. This seems like it would be more work than (1), but it\nwould also allow easier installation without interfering with the rest\nof git.\n\n(3) I could write a proxy server that inserts the header, designed to\nrun on the same machine as the client. This feels rather heavyweight.\n\nAm I missing anything?\n\nThanks,\nDavid\n"},{"id":"254238","messageId":"20141230235610.GC10649@vauxhall.crustytoothpaste.net","threadId":"38264","inReplyTo":"CACejzECGUnH6B2Leq+H6u0Joo1SQmMCZ5UoHja_fK99+6a_iEA@mail.gmail.com","subject":"Re: bearer token authorization with HTTPS transport","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-12-30T23:56:11Z","receivedAt":"2014-12-30T23:56:11Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Dec 30, 2014 at 11:24:09AM -0800, David Renshaw wrote:\n> Hi,\n> I would like to be able to serve a git repository over HTTPS from a\n> web server that requires OAuth2-style bearer tokens for authorization.\n> For more context, see this thread:\n> https://groups.google.com/forum/#!topic/sandstorm-dev/4oigfb4-9E4\n> \n> Does anyone here have any advice about how to convince a git client to\n> add an \"Authorization: Bearer \" header?\n> \n> I can think of a few approaches:\n> \n> (1) I could modify the curl remote helper to insert the header if it\n> sees a \"bearertoken\" config option. I have in fact written a\n> proof-of-concept patch that does this (see\n> https://github.com/dwrensha/git/commit/4da7b64b85b3b6652abe7), but I\n> don't know how much of chance something like this has of getting\n> merged into the mainline git client.\n\nAn idea that might be interesting is to add a framework to select a set\nof authentication types (defaulting, of course, to \"any\"). As part of\nthat, you could add a type, \"bearer\", that uses the password we've\ncollected via the credential helper as the bearer token.\n\nI think that has the best chance of getting merged designwise. I've\nCC'd Peff, as he has touched the area a lot and might have other\nsuggestions.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"254240","messageId":"20141231014209.GA8789@peff.net","threadId":"38264","inReplyTo":"20141230235610.GC10649@vauxhall.crustytoothpaste.net","subject":"Re: bearer token authorization with HTTPS transport","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-31T01:42:10Z","receivedAt":"2014-12-31T01:42:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 30, 2014 at 11:56:11PM +0000, brian m. carlson wrote:\n\n> On Tue, Dec 30, 2014 at 11:24:09AM -0800, David Renshaw wrote:\n> > Hi,\n> > I would like to be able to serve a git repository over HTTPS from a\n> > web server that requires OAuth2-style bearer tokens for authorization.\n> > For more context, see this thread:\n> > https://groups.google.com/forum/#!topic/sandstorm-dev/4oigfb4-9E4\n> > \n> > Does anyone here have any advice about how to convince a git client to\n> > add an \"Authorization: Bearer \" header?\n> > \n> > I can think of a few approaches:\n> > \n> > (1) I could modify the curl remote helper to insert the header if it\n> > sees a \"bearertoken\" config option. I have in fact written a\n> > proof-of-concept patch that does this (see\n> > https://github.com/dwrensha/git/commit/4da7b64b85b3b6652abe7), but I\n> > don't know how much of chance something like this has of getting\n> > merged into the mainline git client.\n> \n> An idea that might be interesting is to add a framework to select a set\n> of authentication types (defaulting, of course, to \"any\"). As part of\n> that, you could add a type, \"bearer\", that uses the password we've\n> collected via the credential helper as the bearer token.\n\nIf you mean something like:\n\n [http]\n authType = bearer\n\nin the config, which would cause us to treat the password we collect\n(whether from a credential helper or prompted on the terminal), I think\nthat would work OK (and you could customize it per-host with the '[http\n\"http://...]' style of config, and use existing credential helpers).\n\nI think the \"username\" in this instance is probably irrelevant, though.\nWe would want to make sure not to prompt for it, which means extra\ncommunication between the http and credential code. It would also be\nnice if the prompt could be customized (it should say \"token\" or\nsomething, not \"password\"). I'd guess in most cases, though, that the\ntoken would come from a credential helper.\n\nAnother option would be to just teach the credential code to accept a\n\"bearer\" field from a credential helper. We would need to:\n\n 1. Teach the credential code that getting a \"bearer\" token is\n sufficient (it does not need to prompt for username/password).\n\n 2. Teach the http code to pull the bearer field out and stick it in an\n \"Authorization\" header.\n\nBoth should be pretty trivial. This approach seems conceptually cleaner\nto me, though it does mean you could not specify a bearer via the\nterminal prompt for a password (e.g., by cutting and pasting from\nelsewhere). I don't know if that is a problem or not. You could override\nit with:\n\n [credential]\n helper = '!f() {\n test \"$1\" = \"get\" || return\n echo >/dev/tty \"No, really, give me a bearer token: \"\n read token Both should be pretty trivial. This approach seems conceptually cleaner\n> to me, though it does mean you could not specify a bearer via the\n> terminal prompt for a password (e.g., by cutting and pasting from\n> elsewhere). I don't know if that is a problem or not. You could override\n> it with:\n> \n> [credential]\n> helper = '!f() {\n> test \"$1\" = \"get\" || return\n> echo >/dev/tty \"No, really, give me a bearer token: \"\n> read token echo \"bearer=$token\"\n> }; f'\n> \n> or similar.\n\nAnd by the way, I'm not advocating that as something people would do on\nthe fly. I mean only that it would be easy to write a drop-in helper to\nprompt people for a bearer token _before_ git makes it to the\nusername/password prompt.\n\n-Peff\n"},{"id":"254313","messageId":"20150106024123.GF1025060@vauxhall.crustytoothpaste.net","threadId":"38264","inReplyTo":"20141231014209.GA8789@peff.net","subject":"Re: bearer token authorization with HTTPS transport","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-01-06T02:41:24Z","receivedAt":"2015-01-06T02:41:24Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Dec 30, 2014 at 08:42:10PM -0500, Jeff King wrote:\n>Another option would be to just teach the credential code to accept a\n>\"bearer\" field from a credential helper. We would need to:\n>\n> 1. Teach the credential code that getting a \"bearer\" token is\n> sufficient (it does not need to prompt for username/password).\n>\n> 2. Teach the http code to pull the bearer field out and stick it in an\n> \"Authorization\" header.\n\nFor the benefit of someone trying to implement this, libcurl has the \nCURLOPT_XOAUTH2_BEARER option. It does requires libcurl 7.33, though.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"254346","messageId":"CACejzEACo17nsA8mqMCt9jHz3mhJsO-dWT07mE9OoPh_rhh_=A@mail.gmail.com","threadId":"38264","inReplyTo":"20150106024123.GF1025060@vauxhall.crustytoothpaste.net","subject":"Re: bearer token authorization with HTTPS transport","fromName":"David Renshaw","fromEmail":"david@sandstorm.io","sentAt":"2015-01-06T16:37:29Z","receivedAt":"2015-01-06T16:37:29Z","isPatch":false,"sender":{"key":"david@sandstorm.io","avatar":null},"body":"On Mon, Jan 5, 2015 at 6:41 PM, brian m. carlson\n wrote:\n>\n> For the benefit of someone trying to implement this, libcurl has the\n> CURLOPT_XOAUTH2_BEARER option. It does requires libcurl 7.33, though.\n\nAs far as I can tell, libcurl supports this option for IMAP, POP, and\nSMTP, but not yet for HTTP.\n\n- David\n"}]}