Thankfully, we have now fixed the issue that caused the new OAuth
templates to break our iPhone App and an update is now live on the App
store.

I thought I'd share our findings as they may prove useful to anyone
else who has experienced problems or who is currently migrating from
xAuth to oAuth in order to meet the new Direct Message access
requirement.

The problem we experienced following the rollout of the new OAuth
screens occurred when a user tried to add their twitter account using
the in-App UIWebView.  This rendered blank instead of prompting the
user to enter their username and password.

We traced the problem to how our OAuth helper was interacting with the
UIWebView.  In our initial implementation the OAuth helper code was
both creating and issuing the OAuth requests, and passing html
responses back to the UIWebView, as text to be rendered.  Although
this worked fine with the old style screens, changes to twitter's anti-
click jacking implementation in the new templates resulted in the
UIWebView being rendered blank.

The solution was simply to get the OAuthHelper code to create the
OAuth signed requests, and pass the NSURLRequest directly to the
UIWebview for loading directly.

Our initial OAuth implementation made use of a PIN based out-of-band
flow, however, as part of our redesign we found that we were able to
move over to an OAuth callback implementation, which provides a much
slicker user experience.

To do this:
1. Login in to twitter's developer page and change your applications
settings to browser and register a nominal callback URL, say your
twitter page (this callback URL is not actually used).

2. Back in your App, define a protocol specific callback url e.g.
yourappname://oauth/callback ours was tweetignite://oauth/callback

3. Define the oauth_callback as your protocol specific url in the
RequestToken request. [Take care not to over URL encode the callback
URL in the header - a big time waster! 8-( ]
e.g.

OAuth oauth_callback="tweetignite%3A%2F%2Foauth%2Fcallback",
oauth_consumer_key="xxxxxxxxxxxxx", oauth_nonce="C8612F28-
D307-446B-88E6-4804282CCB4F",
oauth_signature="xOKzHrQk4HwhOzdGEdWalVPxF6E%3D",
oauth_signature_method="HMAC-SHA1", oauth_timestamp="1306318989",
oauth_version="1.0"

4. Append the protocol specific url as an oauth_callback parameter in
the Authorize URL e.g.

        
https://api.twitter.com/oauth/authorize?oauth_callback=tweetignite%3A%2F%2Foauth%2Fcallback&oauth_token=xxxxxxxxxxxxxxxxxxxxxxx

Once you have implemented this in your OAuth code there are two
choices for implementing the webview.  You can either spawn the
request externally in mobile safari, and add your protocol specific
callback URL to your Info.plist, which will cause your app to re-
launch when it gets the callback.

To get the tokens add
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL
*)url to your AppDelegate and grab the tokens from the oauth_verifier
to complete the flow.

Or alternatively, as in our case continue to use the embedded
UIWebview, which actually receives the callback URL directly in
 -(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
(NSURLRequest *)request navigationType:
(UIWebViewNavigationType)navigationType
here you can grab the tokens from the oauth_verifier to complete the
flow.

The main reason we opted for the embedded UIWebView was because our
TweetIgnite App allows the user to add multiple accounts, and we found
that the cookies twitter sets after adding the first account makes it
difficult to add a second, as the first account is still logged in and
there is currently no option on the new screens to log in as different
user.

With the embedded UIWebView approach you need to programmatically
clear any cookies twitter sets, before launching a new UIWebView so a
new account can be added.

Thanks to Ben at twitter for his help with this, and hopefully this
will be useful to others migrating from xAuth to a full OAuth flow.

Best regards,
Clive

@clivetwist
@tweetigniteapp
[ http://itunes.apple.com/app/tweetignite/id411873391?mt=8 ]

On Apr 29, 6:36 pm, bitrace <clive.tw...@googlemail.com> wrote:
> Hi Matt,
>
> While we welcome improvements to the OAuth screens making it clearer
> what an App can or can not do on a users behalf, the changes that you
> have rolled out have broken our iPhone App TweetIgnite currently live
> in the App store.  [http://itunes.apple.com/app/tweetignite/id411873391?mt=8
> ].  Our App uses an OAuth PIN/out-of-band flow.
>
> As far as I am aware we formatting our OAuth requests correctly (it
> all worked before) and indeed we do receive back the html for the
> Authorisation page, however it is being rendered in the UIWebView as
> blank!
>
> Some investigation indicates that the style sheet may contain an
> incorrectly formed link:
>
>  <link rel="stylesheet" type="text/css" href="//ajax.googleapis.com/
> ajax/libs/yui/3.3.0/build/cssfonts/fonts-min.css">
>
> should this not be:
>
>  <link rel="stylesheet" type="text/css" href="http://
> ajax.googleapis.com/ajax/libs/yui/3.3.0/build/cssfonts/fonts-min.css">
>
> Also the html returned from our OAuth request contains:
>
>  <style type="text/css">
>       html { display:none; }
>     </style>
>
> which is clearly why the page is being rendered blank.
>
> Not sure if this is due to how you now handle certain user-agent
> headers? The user-agent presented by our App is TweetIgnite/1.0.3
> (iPhone; iPhone OS 4.3).
>
> I would be grateful for some help to resolve this?  It would also be
> good to get advanced warning of future changes, and even have the
> ability to test against them before they go live.
>
> Best regards,
> Clive Twist
> @clivetwist
>
> On Apr 28, 10:02 pm, Matt Harris <thematthar...@twitter.com> wrote:
>
> > Hey Developers,
>
> > Some of you may have noticed already that earlier today we deployed a
> > redesign of the OAuth screens.
>
> > We know both you and your users have been asking for better clarity about
> > what an application can see and do with an account and these screens are a
> > step towards doing that.
>
> > One of the areas we wanted to improve is showing the details of your
> > application. If you visit the new screens you will see we've separated your
> > application details from the permissions that are being requested. We did
> > this to help users see that it is your application, not Twitter's. Remember
> > you can update your application details at anytime 
> > onhttp://dev.twitter.com/apps.
>
> > Mobile and international support has also been improved and we now use the
> > same rendering templates as those created for Web Intents. This ensures the
> > design matches the rest of #newtwitter and, more importantly, works
> > cross-browser, cross-platform, and multilingual.
>
> > We hope you find the new designs more welcoming and friendly. Let us know
> > what you think.
>
> > Best,
> > @themattharris
> > Developer Advocate, Twitterhttp://twitter.com/themattharris

-- 
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