That answers all of my questions. Thank you very much!
On May 27, 4:41 pm, Taylor Singletary
wrote:
> Hi,
>
> We're always working on making the documentation better and I can see how
> some of these aspects of OAuth would be difficult to grok when you're used
> to other means.
>
> One way I like to think about this is: Think of your HTTP request as an
> envelope. The URL is the address. Your consumer key and access token is the
> "sender's address." Your POST body is inside the envelope. And the postage,
> ink, bar codes and such are your HTTP headers, including your OAuth
> "Authorization" to send this letter to the recipient.
>
> Specific Answers below:
>
> > 1. Can an application have multiple access tokens open at the same
> > time, for different accounts? Or is the previous access token
> > invalidated as soon as a new user is authorized?
>
> Absolutely. Your application is its own entity. You could have 1 user. You
> could have 5 users. You could have millions. Each of those users in your
> system would have an access token associated with them (which is actually
> two fields you would store, an "oauth_token" and "oauth_token_secret"). The
> only time access tokens expire in our OAuth implementation is when the user
> manually severs the connection in their settings page, or if you re-prompt
> them for access by invoking the OAuth flow again, which gives them the
> opportunity to deny the request. The user is always in control of whether
> your application can act on their behalf.
>
> 2. If it can have multiple access tokens, are the Token and Token> Secret the
> only information needed to authorize a request for a
> > certain user?
>
> They're all you need to identify the user, yes. But you still must sign the
> request using your consumer secret (API secret) as per the OAuth
> specification.
>
> > 3. When using the authorization headers and generating the base
> > signature, are all of the authorization parameters (excluding
> > oauth_signature) merged with the request parameters?
>
> If you use authorization headers, you don't include any OAuth-related query
> parameters on the query string. I recommend using headers exclusively, as
> query-string based OAuth is more difficult to debug and it's better to
> separate concerns: you're requesting a resource, and the OAuth parameters
> don't have anything to do with the resource identified in the URL. The
> authorization HTTP header is more appropriate.
>
> While you don't include OAuth parameters on the query string, you DO need to
> still include any query parameters that are particular to the resource you
> are requesting (like page, count, etc.) in addition to putting them into the
> signature base string construction algorithm. If you have POST parameters,
> they still need to be sent in the POST body. Nothing really changes here in
> the way you use the API as far as the basics of using REST go.
>
> Taylor
