Understood. In other words, there is no way to consume the authenticated parts of the Twitter API on devices without web browsers anymore?
This severe limitation will haunt Twitter in future, without a doubt. Adriaan Pelzer //))//\\//\\||// //\\//7//7///\\ putting you in touch with your crowds http://www.wewillraakyou.com <http://www.wewillraakyou.com>twitter: http://www.twitter.com/adriaan_pelzer linkedIn: http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/ skype: adriaan_pelzer <http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/> +4478 7978 1743 On Thu, May 19, 2011 at 4:00 PM, Tom van der Woerdt <[email protected]> wrote: > Like I mentioned in my post - use the actual browser which includes an > address bar (that's what it's about - without the address bar the user > doesn't know it's actually twitter.com and you might just as well use > xAuth, lol). Use a callback URL which includes a custom scheme > (myapp://oauth_redirect, for example) and catch this URL in your code. > > Tom > > > > On 5/19/11 4:58 PM, Adriaan Pelzer wrote: > > If using a UIWebView is against the TOS, how should app developers > (standalone apps, that is) authenticate without xauth, in the light of > yesterday's announcements? > > Adriaan Pelzer > > //))//\\//\\||// > //\\//7//7///\\ > > putting you in touch with your crowds > http://www.wewillraakyou.com > twitter: http://www.twitter.com/adriaan_pelzer > linkedIn: http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/ > skype: adriaan_pelzer > +4478 7978 1743 > > > > On Thu, May 19, 2011 at 3:53 PM, Tom van der Woerdt <[email protected]> wrote: > >> 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], +1 (512) 750-7596, 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 >> >> >> -- >> 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 >> > > -- > 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 > > > -- > 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 > -- 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
