Please find attached an up to date patch.

> Can you tell us more about what the token is used for and what kind of
>parsing
that is necessary? Is that token usually stored in a file using a
particular
format? I'm not very knowledgable in oauth magic.

The token is sent by the authorization server and can be stored any way
the user wants. I picked a string/file interface for curl itself because
if a user has a token to interact with a service it is convenient to store
it in a file. Here is a sample token (I picked the JSONB representation
because it's easier to read):

{
  "access_token": "xuO8ExwBmJ",
  "token_type": "mac",
  "refresh_token": "uAiE3y9g0e",
  "expires_in": 360000,
  "mac_algorithm": "hmac-sha-256",
  "mac_key":
"RD3tCHmPADqCcUyKF39NaJAZ3pIXcWiLBW9dekrz4da0tLSUtUr3wJ2JdzmxHFLZ"
}

and here is another one (a bearer token, much simpler):

{
  "access_token": "JF0uHZ4Zbr",
  "token_type": "bearer",
  "refresh_token": "cnJ7Azbtlu",
  "expires_in": 3600
}

which can also be represented as:

access_token=JF0uHZ4Zbr&token_type=bearer&refresh_token=cnJ7Azbtlu&expires_
in=3600

Curl parses these tokens into a struct oauth2_token in order to set the
CURLOPT_OAUTH2_TOKEN in libcurl. Because there are slight differences
between URL encoded and WWW URL encoded I modified Curl_urlfmtdecode
appropriately. When moving the parsing into src (tool) I need access to
that. The attached patch resolves this by providing
curl_easy_unescape_form() in libcurl which is useful in general. All token
reading functions have been moved out of the library, leaving libcurl
users to do whatever they would like with their tokens.

YA
­­­
Learn about GPT services and architectures on Confluence.
<http://confluence/display/GPT/GPT+Architecture>

On 3/8/13 2:29 PM, "Daniel Stenberg" <daniel_at_haxx.se> wrote:

>On Thu, 7 Mar 2013, Yves Arrouye wrote:
>
>please don't top-post!
>
>> No I didn't post a patch, I sent you a link to the clone I have on
>>Github.
>
>Can you please post your work as a patch (or patch series) here?
>
>> So I just moved the token reading code outside of lib. It depends on
>> Curl_urlfmtdecode for reading tokens that are in
>> application/x-www-form-urlencoded format (I modified that function as
>>part
>> of my patch to support both URL encoding and the form variant).
>>
>> What would be best in curl?
>>
>> 1. Keep the simple token parsing function as a courtesy to users in the
>> lib (but remove the one that reads from a file)?
>> 2. Have my own decoder in the token parsing code since it's now outside
>>of
>> the library? (Seems like a lot of duplication).
>> 3. Some other option I haven't thought about. Maybe add a
>> curl_easy_unescape_form that can be called by anybody, and rely on that?
>> You may deem this more generic and therefore more useful than the token
>> reading function.
>
>Can you tell us more about what the token is used for and what kind of
>parsing
>that is necessary? Is that token usually stored in a file using a
>particular
>format? I'm not very knowledgable in oauth magic.
>
>--
>
> / daniel.haxx.se
>-------------------------------------------------------------------
>List admin: http://cool.haxx.se/list/listinfo/curl-library
>Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html