How to make Chrome remember password for an AJAX form?
Solution 1
I have found a dirty workaround for this problem, by inserting an invisible iframe and targeting the form to it:
<iframe src="/blank.html" id="loginTarget" name="loginTarget" style="display:none">
</iframe>
<form id="loginForm" action="/blank.html" method="post" target="loginTarget"></form>
The corresponding JavaScript:
$('#loginForm').submit(function () {
$.post('/login', $(this).serialize(), function (data) {
if (data.status == 'SUCCESS') {
window.location = data.redirectUrl;
}
})
})
The trick is, that there are really two requests made. First the form gets submitted to /blank.html, which will be ignored by the server, but this triggers the password save dialog in Chrome. Additionally we make an ajax request and submit the real form to /login. Since the target of the first request is an invisible iframe the page doesn't refresh.
This is of course more useful if you don't want to redirect to another page. If you want to redirect anyway changing the action attribute is a better solution.
Edit:
Here is a simple JSFiddle version of it. Contrary to claims in the comment section, there is no reload of the page needed and it seems to work very reliably. I tested it on Win XP with Chrome and on Linux with Chromium.
Solution 2
Are you able to change the form's action
value to data.redirectUrl
and let the form submit as usual? This should trigger the browser's prompt to save the username and password.
$(form).submit(function () {
$.post($(this).attr('action'), $(this).serialize(), function (data) {
if (data.status == 'SUCCESS') {
$("form#name").attr('action', data.redirectUrl);
}
}
...
Solution 3
Have a read here - why doesn't chrome recognize this login form? .
The important comment is:
Yes, it doesn't work when you remove return false. You will need to rewrite your code. Chrome does not offer to save passwords from forms that are not "submitted" as a security feature. If you want the Save Password feature to work, you're going to have to ditch the whole fancy AJAX login.
So you could maybe consider removing the Ajax and just letting the Form post to login, this will probably be the only way for Users that do not have JavaScript enabled to login with your form too.
Solution 4
I have fixed it using this way:
<form action="/login"></form>
And the JavaScript:
$(form).submit(function () {
if(-1 !== this.action.indexOf('/login')) {
var jForm = $(this);
$.post(this.action, $(this).serialize(), function (data) {
if (data.status == 'SUCCESS') {
// change the form action to another url
jForm[0].action = data.redirectUrl;
// and resubmit -> so, no AJAX will be used
// and function will return true
jForm.submit();
}
});
return false;
}
}
Solution 5
In my case Chrome didn't remember password because there were two different inputs of type password in one form (create/login in one form). The issue in my case was solved by using javascript manipulation of removing one of the input of type password so that browser could decide which submitted fields contains credential data.
Related videos on Youtube
Alex
Updated on October 01, 2020Comments
-
Alex over 3 years
I'm using AJAX for fast input validation on my login page. If everything is correct, the user is redirected.
Here's the code:
$(form).submit(function () { $.post($(this).attr('action'), $(this).serialize(), function (data) { if (data.status == 'SUCCESS') { window.location = data.redirectUrl; } } ...
It works really well in all browsers. But there's a problem in Chrome. It doesn't offer to save the password.
When JavaScript is turned off, the password is saved, so the problem is definitely in redirection to a new location.
How can I fix that?
-
Alex almost 13 yearsThis line alone doesn't redirect at all. If I add window.location = data.redirectUrl; after it, nothing changes. Chrome still refuses to save the password...
-
Marcel almost 13 years@Alex: Are you possibly
preventDefault()
orreturn false
ing somewhere? Get rid of that to let the form do what it usually does. -
Alex almost 13 yearsNo, I'm not doing that. I guess that's just Chrome's bug and it can't be fixed by a web developer...
-
Eivind almost 13 yearsHave you tried doing this, and then doing a $('form#name').trigger('submit');
-
Roman Starkov almost 12 yearsOne other thing you can ditch is support for password saving in Chrome, and let the users bug Chrome developers to fix the browser instead.
-
Aaron J Spetner over 10 yearsIndeed, it did seem so - although it seems to have stopped working again (Chrome 29)
-
alex.net over 10 yearsRight it's weird it's like they disabled it again in 29
-
streetlight about 10 yearsInsanity. Chrome needs to support this!
-
EleventyOne about 10 yearsIt's important to highlight that even with this solution, the current page is still reloaded. So although you aren't redirecting to another page, you are reloading your current page. Chrome makes it very difficult for SPAs to get Chrome to remember a user's password. Related question: stackoverflow.com/questions/21191336/…
-
hegemon almost 10 yearsThis solution works in my app. There's no need to reload whe whole page, only iframe address should change. I've also had to make the target page (blank.html, renamed to blank.php) return a random string to make it work. It' is also wise to use method="post", so that plaintext passwords don't get stored in the server's access log.
-
zeitgeist87 almost 10 years@hegemon Thanks I added method="post", but you don't have to reload the page or the iframe. Just remove "window.location = data.redirectUrl;" entirely. I just added that, because it was part of the original question. On my server blank.html does not exist, so the server returns an 404 error, but it still works.
-
Tiago Sippert over 9 yearsYou don't need to create an iframe, just use action="#"
-
weisjohn almost 9 yearsOn Chrome Version 41.0.2272.104 (64-bit), 1Password prompted, but Chrome didn't
-
Normadize almost 9 yearsI can also confirm that this does not work in Chrome 42.0.2311.90
-
Conan almost 9 yearsDoesn't seem to work in Chrome Version 42.0.2311.90, even the JSFiddle example doesn't work.
-
mkurz over 8 yearsChrome 46 fixed its wrong behaviour - no workarounds needed anymore. See stackoverflow.com/a/33113374/810109
-
mkurz over 8 yearsChrome 46 fixed its wrong behaviour - no workarounds needed anymore. See stackoverflow.com/a/33113374/810109
-
mkurz over 8 yearsChrome 46 fixed its wrong behaviour - it is working now! See stackoverflow.com/a/33113374/810109
-
mkurz over 8 yearsChrome 46 fixed its wrong behaviour - no workarounds needed anymore. See stackoverflow.com/a/33113374/810109