Clive, Congratulations on the new release—it works great! And thank you so much for writing up your implementation in this detail. I'm glad it's come together and I'm glad you've been able to use the callbacks mechanism to improve the flow. Hopefully we're at a point in mobile platform development now where OOBs become a real rarity for users, and we can use callbacks for better app integration in all sorts of ways.
Also, thanks for your patience and enthusiastic working with me to get the problem diagnosed. It was incredibly helpful to get your feedback and assistance, and took a bit of stress out of that weekend! I really appreciate it. On May 25, 2011, at 3:53 AM, bitrace wrote: > 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. For what it's worth, the `force_login` parameter which we'll release soon on the authorize flow is a solution to this problem. (As mentioned in some of the other threads.) Regards, Ben -- @benward Platform Developer, Twitter > 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. > > 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 -- 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
