1. Yep
2. NO. There's no difference in oauth/authorize and oauth/authenticate,
except that authenticate will simply pass the "accept/deny" screen if
the user has already accepted the app. Also, don't display it in a
WebView, use the normal browser instead and use a callback URL with a
custom scheme - for example myapp://. Let the browser redirect this URL
back to the app. Again, do NOT use a UIWebView - I'm pretty sure that
that's against the TOS, and if it's not, it soon will be.
3. Yep
4. Yes, you will need to store the consumer token and secret in the
code, and store the user's token and secret in the keychain (or
somewhere else, secure).
The OAuth flow is no different for mobile devices than for desktops.
Tom
On 5/19/11 4:45 PM, Andrew W. Donoho wrote:
Gentle Twitter Support Folks,
There is an ambiguity in the OAuth flow for mobile devices. As I now
have little time to move from xAuth to OAuth, I would appreciate it if
Twitter Support would confirm the following OAuth flow which uses your
routes.
1) Use "POST oauth/request_token" to get the access token needed for
the user web dialog.
2) Upon receiving the request token, open a web view using "GET
oauth/authorize". This is the ambiguous path for mobile devices. It is
specified that this path must be used for desktop devices. As a mobile
device is really a wireless desktop device, I believe Twitter wants me
to use this route in lieu of "GET oauth/authenticate". Other vendors
also allow the specification of whether this is a mobile device. They
then provide a web authorization dialog appropriate for a narrow
screen. It does not appear that Twitter offers this functionality.
Could you please confirm this? Finally, as my app runs on an iPad,
what is the preferred web view width? (To support both portrait and
landscape orientations, it needs to be less than 768 pixels. 600
pixels is a common, Apple suggested, width.) Could you please
enlighten me to what is Twitter's preferred authorization web view width?
3) Use "GET oauth/authenticate" to acquire the access token and access
secret.
4) As I haven't yet requested my new consumer key and, hence, do not
know some things, will I also be maintaining a consumer secret for my
OAuth signature mechanism?
Thank you for your support.
Anon,
Andrew
P.S. Thank you for the two week extension for our xAuth to OAuth
transition. Because Apple may still reject my app for unrelated to
Twitter issues, four weeks is still a totally inadequate period to
ensure a zero downtime transition. Please recognize both the risks to
our business and the hardship you are imposing on small organizations.
Furthermore, Apple's WWDC conference occurs in the middle of your
current conversion schedule, this only allows me, in effect, 3 weeks
to make this change. You can really hurt us with your imposed
schedule. While I doubt that is your intent, it is, nonetheless, a
likely outcome. Please double, at least, your conversion period to 8
weeks.
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
[email protected] <mailto:[email protected]>, +1 (512) 750-7596,
twitter.com/adonoho <http://twitter.com/adonoho>
"When you can't imagine how things are going to change,
that doesn't mean that nothing will change.
It means that things will change in ways that are unimaginable."
Bruce Sterling, January 02, 2009
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker:
https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
<https://groups.google.com/forum/#%21forum/twitter-development-talk>
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
