Tom, Could you clarify :
If using a web view is against the ToS, could you state which section ? And if "it soon will be" (which conflicts with the above), what makes you think so ? Did I miss something ? Also, if someone from the Twitter team could confirm either of these, this would be much more helpful. On 19 May 2011, at 16:00, Tom van der Woerdt 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
