10. 2010.05.24
Delegated identity verification for uploadAndPost
(OAuth Echo for uploadAndPost)
http://j.mp/raffi_echo2
2010 6 25
11. POST /upload
with OAuth header for GET /account/verify_credentials
GET /account/verify_credentials
with given OAuth header
2010 6 25
12. POST /uploadAndPost
with OAuth header for POST /statuses/update
POST /satuses/update
with given OAuth header
2010 6 25
13. POST /uploadAndPost
with OAuth header for POST /statuses/update
401 Unauthorized
POST /satuses/update
with given OAuth header
2010 6 25
14. However, the Consumer has a problem because
it is charged with generating the signature, but it
doesn't know the final caption for the signature
because it doesn't know the URL. This means
Twitter is going to need to do some work.
http://j.mp/raffi_echo2
2010 6 25
15. POST /uploadAndPost
with OAuth header for POST /statuses/update
+ X-OAuth-Payload
POST /satuses/update
with given OAuth header + X-OAuth-Append-Payload
2010 6 25
18. This is not yet implemented on the Twitter
side, but it will hopefully be soon. I'm definitely
soliciting feedback. http://j.mp/raffi_echo2
2010 6 25
25. Coming soon: a solution for Open Source
applications using OAuth with the Twitter API
http://j.mp/twitter_dev_talk
2010 6 25
26. 1. You store your API Consumer Key in your application distribution
(but never your secret!).
2. A user downloads/installs/checks out your open source
application and runs it for the first time
3. Your application builds a URL to our key exchange endpoint, using
your consumer key.
4. You send the user to that URL in whatever way makes sense in
your environment.
5. That user will approve your application's request to replicate itself
on the user's behalf.
6. The user is presented with a string that they are asked to paste
into your application. The string will contain an API key and secret,
in addition to an access token and token secret for the member:
everything that's needed to get the user up and running in your
application.
7. The user pastes the string into your application, which then
consumes and stores it to begin performing API calls using OAuth.
2010 6 25
27. 1. You store your API Consumer Key in your application distribution
(but never your secret!).
2. A user downloads/installs/checks out your open source
application and runs it for the first time
3. Your application builds a URL to our key exchange endpoint, using
your consumer key.
4. You send the user to that URL in whatever way makes sense in
ck=KIyzzZUM7KvKYOpnst2aOw&
your environment.
cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&
at=54221utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&
5. That user will approve your application's request to replicate itself
ats=FFdeOzzzzEwxOBWPPREd55 dKx7AAaI8NfpK7xnibv4Yls
on the user's behalf.
6. The user is presented with a string that they are asked to paste
into your application. The string will contain an API key and secret,
in addition to an access token and token secret for the member:
everything that's needed to get the user up and running in your
application.
7. The user pastes the string into your application, which then
consumes and stores it to begin performing API calls using OAuth.
2010 6 25
29. We're only allowing open source applications
for now. We may consider other use cases in
the future.
I'll post a new message when things are good
to go and we're ready to accept applications
into the feature. http://j.mp/twitter_dev_talk
2010 6 25
