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 <i...@tvdw.eu> 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 <i...@tvdw.eu> 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.
>>  a...@ddg.com, +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

Reply via email to