On 5/20/11 6:36 AM, Andrew W. Donoho wrote:
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?
I don't work for Twitter - let's get that cleared up first. Mr. Harris does.
However: since I assume that you will want R/W/DM permissions, you
should use /oauth/authorize. Also, since a mobile device normally stores
the tokens in a keychain or some other secure mechanism, the user will
only have to go through the process once. Also, since only
/oauth/authorize supports oauth_callback (may be wrong there) it's the
recommended way for non-web applications.
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?
Absolutely.
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.
Rules: it's apparently not against the TOS to use a WebView, but
everyone I asked thinks it's best to use the normal webbrowser. The user
then gets an additional layer of security, because an application cannot
inject JavaScript in this browser, and the user will recognize that he's
logging in on the actual twitter.com site by looking at the address bar.
If possible, use the normal webbrowser.
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.
[email protected] <mailto:[email protected]>, +1 (512) 750-7596,
twitter.com/adonoho <http://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
<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
