We have universal links implemented and are able to deeplink our users from website to App. Lets say our domain is xyz.com
The challenge we are facing is with Deeplinking our Email traffic to our App. Our marketing team uses Responsys and the marketing email we send have links in them with domain xyzemail.com. When the user clicks on these links they user gets redirected to our actual domain xyz.com
My question is what needs to be done so that email links also deeplink to our App when users clicks on email links with domain xyzemail.com?
Trying to Deeplink traffic from Emails to MobileApps
Not sure how to do this without using services of a vendor like Branch or Appsflyer
Currently when the user clicks on xyzemail.com links we open the actual page on xyz.com on safari browser
Unfortunately the universal links don't handle redirects.
The only way to make it work is to host the apple-app-site-association file on that exact domain name "xyzemail.com" from the link, and add it to the entitlements file.
It doesn't matter which app is showing the link (an e-mail client or another app), it will work from all apps.
Related documentation here
Include xyzemail.com to your supported applinks in Xcode project.
Via Capabilities -> Associated Domains target setting.
You also need to put the app association file on xyzemail.com
Related
I'm trying to link our iOS app to our website with Lastpass. For most sites/apps, Lastpass will filter your list of passwords to the ones that match the app you're trying to log into. For example, if you have a password for mysite.com in LP, if you open up the mysite.com iOS app, the list of passwords will be filtered to the one for mysite.com.
Our app does not filter. When we tap the password field, all available passwords show up and we have to navigate to the password for our website to autofill. We would like this to work like it does for other app/site combos.
I have already deployed the app association file to my website and added the Entitlements to the app (applinks and webcredentials) but it still doesn't work. Any thoughts?
Did you add the site to your app's Associated Domains Entitlement? You need to do that in addition to adding the Apple App Site Association file to your site which you said you've done already.
Documentation here: https://developer.apple.com/documentation/security/password_autofill/about_the_password_autofill_workflow
How does apple make sure that hackers can't push fake apps with fake domains to work with iOS password autofill feature?
For example, if a hacker creates an app with its domain as linkedin.com, the user could be using the Password Autofill feature and fake app will pass linkedin.com as service identifier to Autofill extension.
I found some documentation around how associated domains work for universal link to make sure that authenticity of service identifier or domain is ensured.
Here is the link to tha documentaion I read: https://developer.apple.com/documentation/security/password_autofill/setting_up_an_app_s_associated_domains
Also if password autofill uses the same mechanism as universal link and with associated domains in an app allowing mutiple domains. which domain would autofill extension pick up, when we try to use autofill extention with a native app ?
There is a two-way link between the app and the web site.
The app lists its associated domains in the info.plist file.
The web site at the associated domain provides the bundle IDs its supported apps in apple-app-site-association file.
In order for password autofill to work, both parts of the link need to be in place.
Looking at the example you proposed for linkedin.com.
The attacker can publish an app that lists linkedin.com as an associated domain.
The app has a bundle id, say, com.badapple.trickyapp
This bundle id won't be listed in the linkedin.com apple-app-site-association file, because the attacker doesn't have the ability to change that file; It is controlled by linked in.
Because there is no match, autofill won't be automatically triggered.
How about the other way?
The linkedin.com apple-app-site-association will contain the bundle id for their app, say, com.linkedin.app.
The attacker can't publish an app with that bundle id, because there is already an app on the store with that id (The LinkedIn official app), so they have to use a different bundle id.
Also, the bundle ID needs to include the team identifier, so only apps from the LinkedIn team can possibly match
This is back to the first case; no autofill
Essentially you need control of both the app and the website content for autofill to be triggered.
If there are multiple domains listed in an app, and the relevant site associations are in place, then iOS will offer multiple password choices on the quick type bar. If there are more matches in the Keychain (or whatever password provider the user is using) then they can use the "passwords..." button to see all matches in a table view and choose the relevant account details.
I have two separate apps that run against the same Firebase instance (db). I am adding email link authentication for them. The first one went well. I added the dynamic link domain to use (e.g http://one.page.link), and provided that in the iOS app as associated domain. When the email link is tapped it goes to the 1st app and logs in.
I started adding link authentication to the second app. However, when I send the email link, it references the same domain (http://one.page.link), and hence opens the 1st app on the device when tapped, instead of the second app. I would like it to send the link using a different dynamic domain (e.g. http://two.page.link), so I can associate it for the second app, resulting in the second app opening when it is pressed.
Is it possible to configure the dynamic link domain for the app?
Alternately, is there another way to achieve the same?
I was able to achieve it on iOS using a custom scheme to redirect to the right app based on the ibi or ipbi value in the firebase dynamic link.
Firebase still sends the same link. So, no change on server. On the client, if the ibi parameter in the url is another app, redirect to that app using a custom URL scheme to open the app. That app then reads the contents of the url and handles sign in if its for it.
I have one app where users can create accounts and log in. Other apps will use this account to send in information on app usage.
As of now, users go from the normal apps to the login app via deep-linking, and they send their URL scheme to the login app, so the login app can return them afterwards using this URL scheme. A token is also sent back which is used to identify the user.
To get this to work the normal apps need an URL scheme in their Info.plist however. Logging in with Facebook or Twitter, this is not necessary.
Is there any way to do this without needing the URL Schemes in the Info.plist?
You could probably build a system to accomplish this using Branch deep linking with appended query param links and our match_guaranteed link parameter. That would let you pass data around without needing to hard-code the URL scheme into your client apps, because all of that configuration is handled server-side. It also covers you in the situation that one of the apps isn't installed.
I imagine it would look something like this:
Set up the 'master' app with a Branch key
Set up each client app with its own Branch key
Build an appended params link from the client app into the master app, including some sort of identifying token(s) for the client app. This token could even be the exact return link needed, which you can generate in advance
Do whatever you need in the master app with the sign in or registration
If successful, send the user back to the client app either by building an appended params link, or using the pre-generated link if you passed that over initially
I'm trying to intercept link and login a user, then send them on to Safari and have the page load with no authentication request.
So, what I'm doing so far...
I register a custom URL scheme for my app. Call it "myhttp". Now someone clicks on a link (say from an email) of myhttp://secured.com/foo and my app runs. The apps pulls the user's credentials from somewhere and makes a call to the real URL with an NSURLConnection. The NSURLConectionDelegate implements connection:didReceiveAuthenticationChallenge and I navigate through the security layer fine. Next I try loading the same url using the UIApplication openURL method to bring up Safari, but I still get an authentication check.
I thought this would work because I read the follow in the Apple documentation.
Credentials stored in persistent storage are kept in the user’s keychain and shared among all apps.
And when I check the NSURLCredentialStorage I can see the credentials I just used stored there with the correct information, protection space, scheme, etc, but clearly I'm doing something wrong or I wouldn't be getting an authentication challenge when I switch to Safari.
So the question is, did I just screw up somewhere along the line, forget some important bit or am I going about this the wrong way?
This wasn't possible before iOS 8, but is now with the Shared Web Credentials feature.
Add a com.apple.developer.associated-domains entitlement to your app.
This entitlement must include all the domains with which you want to
share credentials.
Add an apple-app-site-association file to your website. This file must
include application identifiers for all the apps with which the site
wants to share credentials, and it must be properly signed.
When the app is installed, the system downloads and verifies the site
association file for each of its associated domains. If the
verification is successful, the app is associated with the domain.
An app can share credentials with any associated domains by calling
SecAddSharedWebCredential and SecRequestSharedWebCredential.