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
Related
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
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.
In iOS 11 they have introduced password autofill which fills the username and password in iOS app like the same way it does in Safari, User goes to website first, logged in save the username and password in keychain and then open app were the fields are automatically populated, the username and password
can it be implemented in other ways, like I logged in the app first and then while going on the website through Safari it automatically fills the username and password?
Is there any documentation or articles regarding it?
Editing My Answer:
Looks like it is possible to do so. The same kind of association we can see in SharedWebCredentials which is released in iOS8. Using SharedWebCredentials doing in both ways is possible. From app to website and website to app. Assuming Password autofill in iOS11 has done on top of this.
Here is how the association will happen.
We have entitlement certificate for an app where we will provide domain to be linked with. Then we have a website where we will hold information in JSON format related to that website. In that JSON, you have to put your bundle identifier. So when the user saves this passwords and logs in through app. Then the app entitlement file will provide the web address to safari. Safari will bring that JSON file and validate the bundle identifier is same or not. If validation success it will populate username and password.
For more info: Password Autofill in iOS 11
I asked about this at the developer labs at WWDC and was informed that it's possible. The key is that the new password autofill is based on the existing Shared Web Credentials API, which works both ways. If you use that API to save credentials from your app, they'll be available in Mobile Safari. Shared Web Credentials was the topic of a 2014 WWDC session.
I haven't tried it yet, but based on the source I'm pretty confident that it should work.
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 facing a strange Facebook plugin behaviour.
Everything was fine until friday (07/08/2015). I was posting statuses without any problem, but now after I'm entering a login and a password of a test user account (App Settings -> Roles -> Test Users) Facebook showing me an error:
Given URL is not allowed by the Application configuration: One or more of the given URLs is not allowed by the App's settings. To use this URL you must add a valid native platform in your App's settings.
ATM I'm testing my app for the iOS platform and I can't add it, cause I don't have an app store ID yet.
So what am I supposed to do to test my app's facebook functionality before posting it to the app store?
You dont need to set up the store id to test the app as long as your app isnt live. At least in my case I remember adding the desired platform from the settings in the facebook dev console , then typing in the Bundle id and saving. after that I was able to test with users added as test users under roles.