Tom,
Thank you for your answers. As I read other threads, I am finding
ambiguity reemerging. Pardon my pedantry, I want to nail this down correctly
the first time. As you know, I have a hard deadline to get these fixes
implemented and deployed.
It appears that there is a difference between /oauth/authorize and
/oauth/authenticate. In a separate thread:
On May 19, 2011, at 15:17 , themattharris wrote:
>> You said you were restricting this permission to the OAuth /authorize web
>> flow only. Will /oauth/authenticate (Sign in with Twitter) support the new
>> permission?
>>
> The R/W/DM permission can only be granted through the /oauth/authorize
> route. Sign in with Twitter cannot be used to grant R/W/DM.
Could you confirm which route you want mobile devices to use?
Furthermore, Mr. Harris claims the following:
> Be sure to include a path with your callback. For example:
> myapp://oauth_complete
This is at variance with your advice below. Do you concur with Mr.
Harris' view?
Mr. Harris further states:
>> Is using a web view against the Terms of Service (TOS)?
> Using an in-app web view to show the OAuth pages is not against our
> TOS. However, we encourage developers to use the built-in browser
> where appropriate.
Forgive my being gun shy but Twitter has made it clear that client apps
were to get special scrutiny. I want to know exactly what Mr. Harris means by
"appropriate". In my view, leaving my app for Safari is only appropriate when a
user presses a button to go to Safari. Pressing a login button and then seeing
my app swap out for Safari is a confusing and sub-standard user experience. Am
I going to get banned because I deem it a better user experience to stay fully
within my app?
I just want to know what the rules are.
Again, thank you for your time and attention to these issues.
Andrew
On May 19, 2011, at 09:53 , Tom van der Woerdt 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.
Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho
Knowing is not enough; we must apply.
Willing is not enough; we must do.
-- Johann Wolfgang von Goethe
--
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
