13

Update: It appears Twitter has fixed this issue. Clicking the authorize button now works! Thank you all for the responses.

I have a UIWebView that opens and directs to Twitters Oauth/Authorize webpage. The user signs in with there Twitter details and authenticates the use of our application with there Twitter account. This process worked perfect before the release of Twitter 6.37 iOS application. What happens now is when the WebView detects https://twitter.com/oauth/authorize?oauth_token instead of staying in the WebView it opens the native Twitter application and dies. If you uninstall the Twitter application everything works as usually it staying within the WebView. How can I prevent this from happening? I want to stay within my UIWebView and not automatically open deep links. I have been reading about the new URL deep link changes in iOS 9, but not sure of how to stop them from my application to other native applications. Thanks for any help!

enter image description here

mikemike396
  • 2,435
  • 1
  • 26
  • 41
  • I've heard reports that Facebook, Twitter and others block Universal Links from working inside their webviews. This makes me think that there must be a way to intercept and disable this behavior, at least with UIWebView and WKWebView (definitely not with SFSafariViewController). – st.derrick Sep 29 '15 at 19:00
  • I agree, I have tried inside the shouldStartLoadWithRequest method but can't seem to find a way around it. Right before it jumps out of my app it calls https://twitter.com/oauth/authorize?oauth_token as a UIWebViewNavigationTypeFormSubmitted. If I return NO for this case it doesn't submit the page. It would be nice if there was a delegate that is fired when it starts to universal link out of your application. – mikemike396 Sep 29 '15 at 19:05
  • So is this a workable solution for you? I'm curious – st.derrick Sep 29 '15 at 19:34
  • @st.derrick No its not. If I return NO in that case it doesn't load the page or submit to Twitter to authenticate the account, if I return YES it jumps to the Twitter application and breaks the token process. No solution at this point. I wish Twitter would test these things before assuming everyone wants WebView links to open via there application. – mikemike396 Sep 29 '15 at 19:37
  • I wonder if the Twitter iOS team is even aware they've broken this. You can check out the paths in the [apple-app-site-association file](http://twitter.com/apple-app-site-association). – st.derrick Sep 29 '15 at 19:59
  • Anyone find anything? Still no luck here.. – mikemike396 Oct 01 '15 at 20:11
  • 1
    same here, any ideas, guys? – animekun Oct 03 '15 at 17:32
  • looks like it is impossible to prevent from app starting (https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html#//apple_ref/doc/uid/TP40016308-CH12-SW2), then I wonder how I can get auth token? – animekun Oct 03 '15 at 18:41
  • Looking in the [apple-app-site-association](http://twitter.com/apple-app-site-association) file, I don't see a specific "/oauth/authorize" path. There is the "/*/" path, but I would think that would require a trailing "/" for the link in question in order to resolve to a universal deep link. (e.g. https://twitter.com/oauth/authorize/?oauth_token). – vladimir computin Oct 13 '15 at 20:24

3 Answers3

4

As a workaround, in twitter authentication screen we can use the Go button on iOS typing keypad instead of using the sign in button on web view until twitter fixes. Please refer the attached screenshot link for clarity.

Screenshot for the workaround

Bharath
  • 74
  • 3
  • Wow this actually works! Great workaround! I hope Twitter knows about this issue. I submitted a ticket on there twittercommunityforum. – mikemike396 Oct 09 '15 at 11:55
3

I ran into this issue as well and figured out it was because my authorize endpoint was set to https://twitter.com/oauth/authorize?oauth_token="+oauthToken (I believe this was in the original documentation). If you add api as the subdomain: https://api.twitter.com/oauth/authorize?oauth_token="+oauthToken, it will no longer trigger the deep linking and load the twitter app.

Kelly Keller-Heikkila
  • 2,544
  • 6
  • 23
  • 35
Jonathan Lee
  • 31
  • 1
1

My answer to this via a Xamarin question:

Unless Twitter removes/updates the apps section of "https://www.twitter.com/apple-app-site-association" to allow a bypass or a secondary oauth that is not in the apple-app-site-association file I do not see how you would do it. These files are signed and iOS handles them at an OS level.

I have not played around very much with the continueUserActivity delegate and the NSUserActivity object that is passed to apps launched from UNI links, but I do not see a way for the launched app (i.e. Twitter) to return control to the original app, and at that point the oauth call-chain would be broken anyway....

  • Unique. Unlike custom URL schemes, universal links can’t be claimed by other apps, because they use standard HTTP or HTTPS links to your website.

  • Secure. When users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.

Via: https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html

I would report as an issue (bug?) to Twitter's Dev forum: https://twittercommunity.com

Community
  • 1
  • 1
SushiHangover
  • 73,120
  • 10
  • 106
  • 165
  • Thank you for the post! I hope there is a solution in the future. Here is this question posted on TwitterCommunity website -> https://twittercommunity.com/t/disable-twitter-universal-deep-links/53580 – mikemike396 Oct 04 '15 at 23:26
  • I ended up converting to using app level authentication, not ideal since I had to give up (remove) features from the Xamarin based app and launch the Twitter app to allow the user to post, etc... – SushiHangover Oct 05 '15 at 00:36
  • Yea this seems to be the only solution. This isn't idea for us because we have multiple platforms that users can authenticate on. So we would have to build the app level authentication for each platform instead of a web based authentication. – mikemike396 Oct 05 '15 at 12:10