So, now twitter from 25 sep supports universal linking, it means that when UIWebView hits https://twitter.com/oauth/authorize?oauth_token link, it tries to open a twitter app, and if it is there, then it redirects me to auth page with auth error, so I wonder, how can I disable it from code, without uninstalling twitter app, or how I can enable universal linking auth in my xamarin ios app? Is it possible at all?
(similar question but for native: Disable Twitter Universal Deep Links)
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
Related
We are developing two new react native apps, and need to integrate Azure AD authentication at both the places. We also have existing web apps that are Azure AD enabled and the user can open the web links from our (new) native apps.
We have decided to use MSAL library (react-native-msal) to implement the authentication part mainly to support SSO between the native apps + the web apps that we open in the Safari browser.
We have followed all the steps that the react-native-msal library suggests and are able to achieve SSO between the two native apps.
However, when I login to one native app, and try to open the web app link using react linking, the web app prompts for the login credentials.
Note:
For authenticating user through native app, we are using "Authentication Session" with "prefersEphemeralWebBrowserSession = false" which ideally should share the SSO cookies with the Safari browser.
But clearly, this does not seem to work.
I would like to get some understanding on this problem and find out if others are facing this issue too? or is it just us?
In this case you need a preferred user token and send it along with the login request. For capturing the details of the user at the same time I suggest storing the details in the domain wide cookies that is known for all applications.
// Store the user details after login
document.cookie = "msal_details=Paul#xyz-corp.com;domain=.xyz-corp.com;path=/"
// use the user details
var user = getCookieByName("msal_username");
userAgentApplication.loginRedirect(scopes, "&login_hint=" + user);
Lastly, you would need to implement this in your application.
Well, it turns out to be a problem with the simulator. This functionality works only on the physical devices (iPhone/iPad) and not on the simulators.
This should have been documented in the react-native-msal's document though.
I'm using AppsFlyer to test retargeting feature. I've implemented deep-linking using Firebase.
I launch the app on my device using Xcode and click the link below which launches the browser and redirects to AppStore. Since I'm running the debug build directly on the device, it detects as "App not installed".
How can I make sure the link directly opens my App and not redirect to the App store ?
The link is of format:
https://Mycompany.onelink.me/12345678?pid=twitter&c=Paywall&af_dp=MyApp%3A%2F%2FUpgrade&af_web_dp=https%3A%2F%2Fwww.MyCompany.com%2Ffeatures-and-benefits%2Fmobile&is_retargeting=true
In general, you need to configure Universal Links / URL Schemes in your xCode project. Most developers choose Universal Links as they are more secure and work better for most use-cases.
You will also need access the Configure OneLink page on the AppsFlyer dashboard, in order to create a unique OneLink ID for your application, set up the subdomain for your OneLink and input some additional data that is used for authentication (as Universal Links are secure).
You can find all the detailed info and instructions here: https://support.appsflyer.com/hc/en-us/articles/208874366
As this requires a setup on both the client side and and server side, you can request some assistance with the server side configurations and additional instructions on client side configurations at support#appsflyer.com
I know that SFSafariViewController has private cookie storage and other implementations. However, I know that we may write an extension for every (every native system) Swift class.
I need either to share cookies with native Safari, or to open Safari from my app with some header request. At least, how to create an API for getting/setting cookies?
Cookie sharing between SFSafariVC and native Safari has been disabled in iOS >= 11.
At WWDC, Apple announced a change in the behavior of Safari View Controller with iOS 11 in that stored data (cookies, local storage, etc.) will no longer be shared between instances of Safari View Controller. We've confirmed this in-house with a beta version, and this seems to be independently confirmed by the folks at Branch.
From AppAuth-iOS' repo: user whitehatguy
The only API for SFSafariVC is to create a new instance for a given URL. You can't set or modify cookies.
If you need to execute custom code, have a look at WKWebView (iOS >= 8) / UIWebView (iOS < 8). Useful answers: Getting cookies in WKWebView
SFAuthenticationSession was created to allow SSO/OAuth authentication flows, which shares cookies with native Safari but developers have no direct access.
A class that manages sharing a one-time web service login, along with cookies and website data, between Safari and an app, which can also be used for automatic login for other associated apps.
The two cases where you would use SFAuthenticationSession are:
Logging in to a third party's service using an authentication protocol (e.g. OAuth). This option works well for social network applications.
Providing a single sign-on (SSO) experience for applications. This option works well for enterprise companies that have many applications installed on the same device.
SFAuthenticationSession's documentation by Apple
I enabled Associated Domains in Capabilities in Xcode, and it creates a ".entitlements" file as expected. But it also modified a project.pbxproj file, adds com.apple.SafariKeychain = {enabled = 1;}
So I am just curious, why it is enabled, is it useful for some reason?
I couldn't find any documentation about this.
Note: Updated for iOS 12
That entitlement is used for multiple purposes. It covers any feature where your app needs to establish a verified connection to a web domain. This verification is accomplished by placing a static JSON file (called apple-app-site-association) at the root level of your domain which contains your app's fully-qualified App ID, with keys and configuration to enable specific functionality.
It covers a few actual iOS features:
Shared Web Credentials. The identifier com.apple.SafariKeychain actually refers to the original purpose of the Associated Domains capability, which was to enable native app access to credentials stored in iCloud Keychain for your web domain. If a user has already logged in to your web site and saved their password in iCloud Keychain, this feature allows your native app to use those stored credentials.
Password AutoFill. Available in iOS 12. Password AutoFill takes the behavior added to web sites with Shared Web Credentials, and extends it into native apps in a robust way. By establishing Associated Domains for you app, and adding metadata to your text fields, iOS can automatically enter saved web credentials into your native app. when creating a new account or changing passwords, Password Autofill can offer strong password suggestions, based on your organization's password rules. It can also assist the user by automatically filling in a multi-factor authentication code sent via text message, if it can find a field designated for entering that information.
Universal Links. At its simplest, this feature is a secure replacement for the old custom-scheme-based method of launching one application from another, or from a web link. When used to its fullest, it allows you to draw parallels between the information architecture of your website and your native app. When a user taps a web link for your domain, your native app can be launched in order to handle that link. If the app is not installed, a Smart Banner will be presented with a link to the App Store.
Web Browser–to–Native App Handoff. This is a passive version of Universal Links. If a user is browsing your website on a macOS or iOS device, and you have created a site association for the page they're viewing, they will see a Handoff icon on their iOS lock screen which will let them open your app and, optionally, navigate to the native version of the web page they were viewing.
In the Facebook App Settings ☞ Advanced ☞ Authentication I can pick "Web" or "Native/Desktop" as App Type. The info bubble says:
Only select Native/Desktop if you are a Native iOS or Android app,
device, or Desktop app
Actually I am none of those but my app is a Native iOS App as well as a Facebook Page Tab.
Question: Which App Type should I pick?
I did some research and found the following in the Facebook Android Tutorial (under Troubleshoot):
App type Web vs Native/Desktop. Does it matter?: No, it does not
matter. However it's recommended to use the type 'Native/Desktop' for
your app.
What does it mean it does not matter? That does not make sense to me. Why should I have a choice then?
I did some more research on SO and found this statement by #Igy (dev support engineer at Facebook):
If the app's type is set to 'Native / Desktop' it's assumed you
distributed the app's secret key with the binary, and thus the app
access token isn't trusted (and 'getAccessToken' in the PHP SDK will
only work when real users log in, it can't fall back to the app token)
Finally I found this in the Facebook documentation:
Note: Applications that are configured as Native/Desktop apps will not
be able to make API calls that require an application access_token.
I do need to make API calls which require an access token from my page tab app, hence my conclusion is to pick "Web" as the App Type, although I'm having a native iOS app using the same app ID as the page tab app. But will that have any drawbacks on the iOS app?
TL;DR: use 'web' unless you're putting the app secret into the iOS / Android binary
The primary difference (and also the reason that it says 'it doesn't matter' while also giving a recommendation) is that if you choose 'native/desktop' mode, it's assumed that you distribute the app binary with the application secret embedded and the app secret is considered untrusted.
In this configuration, API calls which use the app secret (e.g. creating test users, making API calls on behalf of the app itself like changing app settings, posting achievements, etc) will not work.
If your app doesn't need to use the app secret / app access token, setting it to native/desktop increases the security somewhat as there's one less attack vector for your app.
If you're distributing the app secret with your code you MUST use that option or users could easily determine the app secret and hijack the app itself.