Hi Yves, this is dertainly very interesting. Please keep us informed! For me in the new year is fine...
Best regards, Mischa On Fri, Dec 21, 2012 at 9:30 PM, Yves Arrouye <[email protected]> wrote: > I may not be able to send the patch until after New Year's. I did it at > work, and my company has a policy that says it needs to be reviewed > internally. Everybody's off right now, and me too soon. > > The patch is basically structured as follows: > > - oauth.[hc] defines a structure to hold the known OAuth 2 token types > (bearer and MAC) as well as functions to parse tokens. There is a built in > parser for a token in text/www-url-encoded form, and if configure finds > jsonsl (or if it's under deps on Windows and USE_JSONSL) then tokens in > application/json can also be parsed. The goal is to be able to make a cURL > request to a token endpoint and reuse the response in another cURL call. I > picked jsonsl after looking for a VERY brief time for a simple C json > tokenizer that I could understand in ten minutes or so, but any could > > - http_oauth.[hc] provides for generating the Authorization header. It is > inspired by http_digest.[hc]. > > - I've added a setopt that takes a pointer to a struct curl_oauth2_token > to indicate that one wants to use OAuth 2. I picked the struct rather than > a string to parse so that one could build a token repository wherever one > wants and pass the tokens as needed. It should be easy to expose that > struct to language bindings such as PHP, Python, etc, though I have not > done so. This is a place where I'd need guidance on whether I did right > per cURL's spirit or not. > > - When picking auth, libcurl will pick OAuth 2 as an option. It's ranked > above digest and basic but maybe that could be made dependent on the > security of the token too (e.g. Bearer is lowest, but MAC is highest). I > am not sure. > > - tool_getparam.c, tool_operate.c, tool_help.c and their friends etc. have > been modified. In the tool, the configuration object takes a string, and > it is then parsed and if successfully parsed it is used in a call to > setopt. I wrote code that either takes a filename (including "-") or, with > a #ifdef, takes the token itself or an @filename like seen in other places > of cURL. I have some reservation about passing the token data (including > the secret) in the clear so that's off for now! A more paranoid > implementation may also balk at the user if the file is group and/or > world-readable, but I don't really like nannying people that way. > > - m4/curl-confopts.m4 deals with the --enable-oauth2 option (default is > no) and also looks for JSONSL. In configure.ac I call the new macro and > report on whether OAuth 2 is enabled as well as which token encodings are > supported. > > - Similar changes have been made to the winbuild Makefiles, and options > added there are documented in the README. > > > - docs/curl.1 is updated to document the --oauth2 <file> option as well as > the companion --http-mac-ext <string> (which is how I provide for the > "ext" parameter for HTTP MAC). > > That's it in a nutshell. > > YA > > Learn about GPT services and architectures on Confluence. > <http://confluence/display/GPT/GPT+Architecture> > > > > > > On 12/21/12 11:35 AM, "Oscar Koeroo" <[email protected]> wrote: > > >On 21-12-12 19:32, Yves Arrouye wrote: > >> I have so far a full patch off HEAD for OAuth 2 which supports the > >> generation of a proper Authorization: header for OAuth 2 from a token. > >> Bearer (RFC 6750) and the HTTP MAC (draft-ietf-oauth-v2-http-mac-02) are > >> both supported. The patch has been tested on OS X, Linux, Windows using > >> nmake as well as MingW32. We are using it to interact with our newly > >> designed authentication service (so it's also been tested against a > >> different implementation of HTTP MAC), which is why I cared mostly about > >> generating proper authorization headers, and not about three legged etc. > >> But it's a solid start. > >> > >> I was actually going to ask if there was interest in having me > >>contribute > >> this to cURL. The patch does NOT enable OAUth2 by default (but I can > >> change that, and maybe not enable HTTP MAC by default as it's an I-D and > >> not an RFC; all those things can be discussed). > >> > >> If there is interest, then I'D love to discuss some of my decisions > >>(e.g. > >> take a token file on curl's command line rather than the token data > >>itself > >> so as not to expose it on the command line, though I also have #ifdef'ed > >> support for that) as well as make sure some of them are the right way to > >> integrate with cURL and libcurl (e.g. setting the token through libcurl, > >> where a file did not seem appropriate). > >> > >> Refresh tokens are not supported yet because it's something I'D rather > >> discuss with the list before picking some design over some other. > >> > >> YA > > > >This is interesting. Do you have a more detailed write up, or even the > >source code/patch? > > > > > > Oscar > > > > > > > ------------------------------------------------------------------- > List admin: http://cool.haxx.se/list/listinfo/curl-library > Etiquette: http://curl.haxx.se/mail/etiquette.html > -- Maasstraat 162-III 1079 BK Amsterdam The Netherlands Tel. (+31/0)20-4043782
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
