That answers all of my questions. Thank you very much!
On May 27, 4:41 pm, Taylor Singletary <taylorsinglet...@twitter.com> 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
