I am looking for a way to do AutoFill,SavePassword and Spellcheck in WkWebView
AFAIK
SpellCheck(spellcheck="true"),Autocomplete('autocomplete','off') can be done by specifying HTML Attributes
SavePassword and Autofill can be worked around using stringByEvaluatingJavaScriptFromString and NSUserDefaults
I have an webapp which is going to be loaded in WkWebView and I'd like to facilitate SavePassword,AutoFill and Spellcheck using WkWebView itself.
Does WkWebView provide any interface to directly deal with these ?
Any suggestions are appreciated !
While this DOES allow autofill/keychain to fill credentials on a properly set-up trusted domain through wkwebview, it still does not allow the SAVE/STORAGE of user/pass upon entry. This behavior is strange - meaning one can use their web credentials to sign into an app which also includes this domain as trusted, but the user cannot save their user/pass FROM the app/wkwebview despite it being trusted. There is no documentation from Apple explaining this discrepancy - and many have the same issue.
AFAIK, Apple doesn't allow us to use Autofill in WKWebview because the app may steal your information.
Enable Password AutoFill
Password AutoFill uses heuristics to determine when the user logs in or creates new passwords, and automatically provides the password QuickType bar. These heuristics give users some Password AutoFill support in most apps, even if those apps haven’t been updated to support AutoFill. However, to provide the best user experience and ensure your app fully supports Password AutoFill, perform the following steps:
Set up your app’s associated domains. To learn how to set up your app’s associated domains, see Supporting Associated Domains.
Set the correct AutoFill type on relevant text fields. For an iOS app, see Enabling Password AutoFill on a Text Input View. For a web app, see Enabling Password AutoFill on an HTML Input Element.
https://developer.apple.com/documentation/security/password_autofill
Related
I have this task that need to show the suggested username & password on my app.
something like this that I found [credits to this site]
https://brainsandbeards.com/blog/quick-change-that-helps-ios-users-sign-in-quicker
or something like this
Other way to autofill
But every time I press the 'password' on the top of the keyboard it always goes directly to the list of keychains and not giving the option like the above image showing a suggested account or choose other passwords.
I even followed this documentation:
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_associated-domains
even use an 'alternate-mode' on the associated domain.
I suspect that the webserver we're using is not managed shared credentials enabled server?
Is there a possibility to do this without associated-domain capability?
Thanks in advance!
My app has an embedded WKWebView that we use to show custom user content served from the users organization. A few organizations are using HTTP authentication (NTLM) so I am working on supporting this. I've implemented the necessary delegate function (webView didReceive: completionHandler:) and create a UIAlertController with two text fields to allow the user to input their username and password. Functionally, this works and allows the users to log in to their organizations site.
However, because I'm creating the alert controller in my app, usernames and passwords are saved and suggested using the apps associated domain. While technically this makes sense, it is confusing for our users to be logging in to their website but seeing a password suggestion coming from our domain.
I haven't found any way to get the WKWebView to display its own username and password prompt. I've considered trying to inject some javascript to show the prompt, but I'm far from a javascript expert and I'm concerned about causing issues with existing javascript on our customers sites (and I don't know if it will still use the app domain anyway). Edit - tested this, the app domain is still used.
https://developer.apple.com/documentation/security/password_autofill/ seems to say that there's no way to use a different url.
Is there anyway for the username and password to be saved using the url that is being loaded in the web view instead of the apps associated domain?
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'm developing an internal app that will leverage our corporate Google Drive accounts and will be used on shared devices (iPads shared among teachers and students at school sites).
Is there a way to force GIDSignIn to require a password with each sign-in attempt? Right now, even after calling GIDSIgnIn.sharedInstance().signOut() (or GIDSignIn.sharedInstacne().disconnect()) the user doesn't need to enter their password the next time they access the app. That means, when the device is taken by the next user, they could very easily access the other user's account.
Am I missing something? Do I need to somehow clear the cookies store in the UIWebView that the GIDSignIn process uses?
Where available, the GIDSignIn login process uses a SFSafariViewController, not a UIWebView. It leverages the cookies (as well as passwords) stored in Safari, for a quicker login.
I don't think you would be able to clear such cookies. You should be able to force a Google log out, though, by opening https://www.google.com/accounts/Logout in an SFSafariViewController, though the interaction with the rest of your app may be a bit weird. See Logout link with return URL (OAuth) for a way to provide a return URL which you may try to use to control the process (you'll need to use an URL scheme to return, though).
Note that iOS may prompt to save login information, and then provide said login information to subsequent users. You'll need to disable that in Settings -> Safari -> AutoFill
There may be other ways of achieving it via configuration of the device, but iOS is not really designed for multiple users at the moment.
The Scenario:
A web application that once a new user completes the registration, an email will be sent, containing a URL that once tapped from within an iOS device, the iOS app will be launched. This scenario is a classic scenario to make users use the mobile app.
While implementing it (using URL scheme), we start wondering how secured is this method? Theoretically - a malicious app could sign up to the same URL scheme, and according to Apple:
Note: If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme.
Implementing Custom URL Schemes by Apple
In such scenario, if a user is tapping the url inside the email, it is unknown which of the two (or more apps) will be launched - ours or the malicious one. Lets say a different app is being launched - if its really malicious, theoretically it could mimic the login page of our app and grab the user's credentials.
Are there any best practices that handles such scenario? I've read many articles regarding the issue, all of them claims that the only solution is to wait for Apple to make these url schemes unique.
example1,
example2
I would love hearing about any solution to the issue if exist,
Thanks in advance!
We have to assume the malicious app can intercept any data included in this url and that it's author has been free to reverse engineer any behavior included in your app so it can imitate your UI and any validation your app attempts to perform. However we can also assume that the malicious app is contained in its own sandbox so your app can communicate with your backend privately. The malicious app can imitate any such communication but this does allow us to construct a secret unknown to the malicious app. That gives us at least an opportunity to design some countermeasures.
One option might be:
As part of registration construct a public/private key pair and store it in your app.
Send the public key to your web backend as part of the registration process.
Encode they payload of your URL using that public key.
Now we've sent data to your app which might be redirected to a malicious app but which the malicious app cannot read. That's a partial solution. We still need to be careful to design a UI which does not encourage a user to fall for a phishing attack since the URL might still launch the imposter.
The encoded data might be a token we can use to authenticate the user and therefore never require them to re-authenticate within the app. Then there is no login screen to imitate (though a clever forgery might still be enough to trick users into divulging their credentials).
An alternative might be to use a similar per-user secret stored on the client as a salt to combine with the user's password. Their password alone might then be insufficient to authenticate so a malicious app capturing their credentials is not immediately able to access their account.
Another design could be to allow the user to customize their experience in a recognizable way. You might show their selected profile image on the sign in screen. If that selection is known only to your app then an imitator shouldn't be able to duplicate it reliably (again, no guarantee that means users will catch the deception).
All of this introduces tradeoffs; users might still be tricked into revealing information to malicious apps no matter how different they appear from your legitimate client, client side secrets can be extracted by other attacks, and you need a plan to support users who switch, lose, or upgrade devices. You have to decide if any of this actually improves the security of your users and if it is worth the cost to implement.
Try something like this:
In your email, state that clicking on the URL will launch the app and log you in for the first time then prompt user to enter their new password. Include a token in the URL which, when handled by your app, does a one-off login and put the user on a "New Password" page.
If a malicious app has also registered your custom URL and steals the link, they should (hopefully) not be able to do much with it. Even if they replicate your interface and prompt the user for a new password, it's not going to achieve anything.
edit: After thinking on this further, as long as you have an active attacker, you're pretty much screwed. The attacker could continue to emulate your app, effectively MITMing you, regardless of what you do, as long as they're able to hijack that initial URL. My solution would only work in the most basic of cases, not really reliable.