I have an admin form with username and password fields that is being filled in by Chrome as it has a username and password remembered. I would like to prevent these fields to be automatically filled. I did lots of search and already tried the autocomplete tag (in input and form), displany:none in style tag and the javascript call to dissabled autocomplete... and nothing of these worked.
Can you please give me a hand?
Thanks!
link to gist https://gist.github.com/runspired/b9fdf1fa74fc9fb4554418dea35718fe
<!--
<form autocomplete="off"> will turn off autocomplete for the form in most browsers
except for username/email/password fields
-->
<form autocomplete="off">
<!-- fake fields are a workaround for chrome/opera autofill getting the wrong fields -->
<input id="username" style="display:none" type="text" name="fakeusernameremembered">
<input id="password" style="display:none" type="password" name="fakepasswordremembered">
<!--
<input autocomplete="nope"> turns off autocomplete on many other browsers that don't respect
the form's "off", but not for "password" inputs.
-->
<input id="real-username" type="text" autocomplete="nope">
<!--
<input type="password" autocomplete="new-password" will turn it off for passwords everywhere
-->
<input id="real-password" type="password" autocomplete="new-password">
</form>
I found a work around for chrome. I have not tried this on any other browser. Load the password field as a type="text" then when the page is finished loading change the type to password chrome will not autofill the username and password.
<input type="text" name="newPassword" id="newPassword" value="" class="form-control" autocomplete="off">
<script type="text/javascript">
$(document).ready(function(){
$('#newPassword').attr('type', 'password');
});
</script>
The reason browsers are ignoring autocomplete=off is because there have been some web-sites that tried to disable auto-completing of passwords.
That is wrong; and in July 2014 Firefox was the last major browser to finally implement the change to ignore any web-site that tries to turn off autocompleting of passwords.
autocomplete=offAny attempt by any web-site to circumvent the browser's preference is wrong, that is why browsers ignore it. There is no reason known why a web-site should try to disable saving of passwords.
There are people who bring up a good use-case:
I have a shared, public area, kiosk style computer. We don't want someone to (accidentally or intentionally) save their password so they next user could use it.
That does not violate the statement:
Any attempt by any web-site to circumvent the browser's preference is wrong
That is because in the case of a shared kiosk:
The browser (the shared computer) is the one that has the requirement that it not try to save passwords.
The correct way to prevent the browser from saving passwords
is to configure the browser to not save passwords.
Since you have locked down and control this kiosk computer: you control the settings. That includes the option of saving passwords.
In Chrome and Internet Explorer, you configure those options using Group Policies (e.g. registry keys).
From the Chrome Policy List:
AutoFillEnabled
Enable AutoFill
Data type: Boolean (REG_DWORD)
Windows registry location: Software\Policies\Chromium\AutoFillEnabled
Description: Enables Chromium's AutoFill feature and allows users to auto complete web forms using previously stored information such as address or credit card information. If you disable this setting, AutoFill will be inaccessible to users. If you enable this setting or do not set a value, AutoFill will remain under the control of the user. This will allow them to configure AutoFill profiles and to switch AutoFill on or off at their own discretion.
Please pass the word up to corporate managers that trying to disable autocompleting of password is wrong. It is so wrong that browsers are intentionally ignoring anyone who tries to do it. Those people should stop doing the wrong thing.™
tl;dr: My browser is going to remember my login for your web-site. If you don't like it: that's your problem. I will not sacrifice my preferences for yours.
There is a lot of confusion, or disagreement, on these points. Let me clarify, and put it as plainly as i possibly can:
It's not your job to over-rule the user's wishes. It's their browser; not yours.
And if i don't want the value saved, i will click Nope:
Neither you, nor your managers, nor HIPPA, nor the EU, nor the GDPR, get to over-rule my wishes. It's my browser. I'm the user. I'm in charge.
But you don't get to impose them on anyone else.
But it's a HIPPA-PCI-GDPR-PII violation if we allow passwords to be saved. We need auto-filling turned off!
No, you don't. I'm right. You're wrong. And every browser agrees with me. If you don't like something, i suggest you talk to a therapist about it.
type=text rather than type=password. –
Advised input=password and instead change it to input=text on your fields that contain single-use codes? Also, have you tried clicking No when it asks if you want to save the code? My concern is that if the web-site disabled auto-saving of a one-time-use token, that my browser might then not try to fill the same one-time use token from the last time. –
Advised autocomplete="new-password" on the PSK (password) input stop chrome from doing this (for me). Another work round is to have a second pair of inputs, before the real ones, but place them off-screen (x=-100,y=-100) - if you just hide them (display:none) chrome isn't fooled –
Decca type=password input are actually asking for a password. You might use it for LOTS of different reasons, like I have for the user to enter a PSK, say, for setting up a VPN authentication or DNS zone transfer (TSIG). I do a lot of web interfaces to server management. Saying "just don't use an obfuscated input" is NOT a solution. It's not the saving I have a problem, its the pre-filling with the user's login details for something that is NOT a login form, it just happens to have an obfuscated input & the only way to do that is type=password –
Decca input type='password' and instead change it to input type='text' on your fields that contain single-use codes - so that the browser doesn't try to hide, mask, or otherwise obfuscate the OTP? –
Advised type=password field are logins to that web site, that's a fact, & for the browser to assume they are & fill in the login details IS over-reach on its part. The fact you can't understand this is your failing. –
Decca username, then you click Next and you're presented with a page to enter your password. So a form with a Username (and no password input) should auto-fill. And a form with a password input (and no username) should auto-fill. In other words: if a page has an input type=password then it must fill with the user's password. If the web-developer didn't want it to auto-fill the password, he wouldn't have made it type=password. But he did. –
Advised type=password, to have a hidden input field. So "not a login form" means ANY form that requires a field to be hidden (e.g. for legal regulatory reasons), but is not a login to the web site. This legal requirement is common in banking & medical applications, but might also be expected when users are inputting a share key, entering key name & key would be plain & hidden inputs that the browser would assume was a login to the site, when its not. By always filling them with the user's login credentials, browsers risk creating a security vulnerability –
Decca there's no way around this <- I've found two ways round it, but I'd rather not have to hack the browser to stop it assuming EVERY SINGLE form that has at least one plain & one hidden field is a form for logging into that site. Personally, I'd prefer browsers were just a lot smarter about handling basic authentication then most of these login forms would become unnecessary, but we are where we are - site have been forced into doing their own login mechanisms & so we have this random mess instead of everybody using the built-in authentication mechanism –
Decca id="search", and to to change it from input type="password" to input type="text". –
Advised <input type="password"> to <input type="text">? –
Advised Adding autocomplete="something" attributes does not help me. My form has text type input and Chrome constantly filled it with login data. Adding hidden text type input did not help too. But solution was adding pair hidden input fields with text and password types before visible inputs
<input type="text" style="width:0;height:0;visibility:hidden;position:absolute;left:0;top:0" />
<input type="password" style="width:0;height:0;visibility:hidden;position:absolute;left:0;top:0" />
Tested with Chrome Version 74
I found the solution. !!!!
PROBLEM
my problem was that the username and password saved in the browser was automatically filling my register form
REASON
The problem here is that the password input type is password. it automatically fills in as username without knowing what the parent entry is.
SOLUTION
Adding autocomplete="new-password" to the password entry solved my problem.
It also works in Firefox and chrome. I haven't tested the others.
<input
id="txtSetPassword"
[formControlName]="formControlName"
[type]="show ? 'text' : 'password'"
class="input"
autocomplete="new-password"
[placeholder]="'loginPasswordForm.password.placeholder' | cxTranslate"
/>
I ended up doing something like this:
<input type="password"
id="password-field"
onClick="yourFunction()"
class="form-control"/>
function yourFunction() {
var temporalValue = $('#password-field').val();
$('#password-field').val("");
$('#password-field').attr('type', 'text');
myAjaxRequestPromise(temporalValue).then(function(version) {
//more logic
}, function(errorResponse) {
// Just a hack to fool browsers and do not store my password
$('#password-field').val(temporalValue);
$('#password-field').attr('type', 'password');
// more logic
});
}
And always make sure the $('#password-field').val("") initializes the field without values, it could be whenever you show your modal or on the load page callback
It seems to be working fine for Safari/Chrome/Firefox
It basically switches between input types before doing the Ajax request to the server and in case there is an error we set back again the old value to the input.
<input name="password" type="password" autocomplete="new-password" />autocomplete="new-password" - This attribute's value works for me.
In HTML 5 you can do it in one of two ways...
<form action="demo_form.asp" autocomplete="off">
Or an individual control
<input type="email" name="email" autocomplete="off">
For more info - http://www.w3schools.com/html/html5_form_attributes.asp
© 2022 - 2024 — McMap. All rights reserved.