I'm working on a webapp written in angular that seems to have trouble interacting with the various password managers (Dashlane, LastPass, etc) that are out there. Are there any guidelines around HTML markup and authentication flow to ensure compatibility? This is not just for login flow, but also includes things like password reset, user name changes, and so on.
It appears that this question has already been asked, but not in the context of AngularJS.
From https://lastpass.com/support.php?cmd=showfaq&id=3385
While LastPass can work on most website logins, if you are developing your own site you can help make it LastPass-compatible by using a simple form submit with a username, password, and submit field.
Here's an example:
<form action="https://mypage.com/blah" method="post">
<input type="text" name="username" id="username" value=""/>
<input type="password" name="password" id="password" value=""/>
<input type="submit" value="LOGIN"/>
</form>
As far as what to avoid -- always create the form on page load, even if you hide and show it to people clicking log in, it's better to be there on page load. Avoid ajax for logging in and avoid method=GET
So besides giving name attributes to your controls, LastPass recommends having the login form markup already in the HTML when it is first loaded.
My web application is written using MVC5 and C#.
I have 2 pages where a user can enter their username and password. One of them is the Request Account page, the other is the Login page.
I am seeing different behavior of the Save Password prompt across IE, Chrome and FireFox.
The URIs are:
/Account/RequestAccount
/Account/Login
FIREFOX - Prompts user to Save Password on either page. On submission of the Request Account form the user is offered to save the username/password. If the user opts to save the password FireFox will perform autocomplete when the user returns to the Login form. This behavior is desired and seems correct.
IE & CHROME - Neither of these browsers offer to save the username/password when the Request Account form is submitted. However both browsers offer to save username/password when the user submits the Login form.
Honestly, I don't see how IE or Chrome can make a distinction based on URI and I don't believe that they do. This leaves me with suspecting there may b something incorrect with my form fields except that they work fine on the Login page.
Both of my Login and Request Account pages use identical form field IDs (UserName and Password).
<input class="form-control valid" data-val="true"
data-val-email="The Username field is not a valid e-mail address."
data-val-required="The Username field is required." id="UserName" name="UserName"
type="email" value="" aria-required="true" aria-invalid="false">
<input class="form-control" data-val="true"
data-val-required="The Password field is required." id="Password" name="Password"
type="password">
My question, is there something specific that needs to be done in the Request Account page form fields to trigger the Save Password prompt like FireFox does? Or, does IE and Chrome dismiss the Request Account page as not being an actual login page (somehow)?
Does adding the autocomplete="on" property helps?
IE11 will no longer support it though:
http://msdn.microsoft.com/en-us/library/ie/ms533486%28v=vs.85%29.aspx
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.
Bugzilla Bug 956906 - ignore autocomplete="off" when offering to save passwords via the password manager
Reddit discussion
Chrome's announcement when they began ignoring autocomplete=off
Any 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.
Chrome ignores it
Safari ignores it
IE ignores it
Firefox ignores it
What if I'm a special snowflake?
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:
it is not the web-server that has the oddball policy
it is the client user-agent that has the oddball policy
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.
Put it another way
There is a lot of confusion, or disagreement, on these points. Let me clarify, and put it as plainly as i possibly can:
if i want to save my HIPPA password: that's my right
if i want to save my PCI password: that's my right
if i want to save the "new password for the user": that's my right
if i want to save the one-time-password: that's my right
if i want to save my "first color's favorite maiden" answer: that's my right.
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.
If you have a different opinion
on how your browser should behave
then you
can configure your browser
to suit your personal preferences
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.
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 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.
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"
/>
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
Here's the scenario: I made a Drupal site, with permission for 'view published content-->Registered users' (because I want only registered users to view the content). so, the homepage (login page) actually is an 'access denied' page with login block in it's content area. This is making errors in Google Webmaster Tools homepage index. The homepage for a new unregistered visitor is an access denied page.
So I thought of firing the login action through a custom made HTML login form by using action="<!--URL of login page"-->
Is there any option similar to mentioned below ? (the below mentioned code is just opening the login page after hitting submit. I want a code that will successfully perform the login operation)
<form action="http://siteURL/user/login" method="post">
E-mail<input type="text" name="name" value=""></input> <br>
Password<input type="password" name="pass" value=""></input> <br>
Remember me <input type="checkBox" name="rememberMe" checked><br>
<input type="submit" value="Login"></input>
</form>
I think that your problem could be solved using the Views Module. You could create a page in views and set the URL of your new view to the home page at Administer -> Site configuration -> Site information
Additionally if you ever feel the need to edit a theme output, you can override the template files -> https://www.drupal.org/node/173880
I created html form for registration, where user must fill password input.
Actually if "register" button is pressed, then i process form on the server side and i make redirect. Chrome still offering me if i want to save password on this site (probably because it knows that there is password input on tha form, which was submitted). I wanna dissalow this offer from browser when user is registering.
Try setting autocomplete="off" on your input:
<input type="password" name="password" autocomplete="off" />
https://developer.mozilla.org/en-US/docs/Mozilla/How_to_Turn_Off_Form_Autocompletion?redirectlocale=en-US&redirectslug=How_to_Turn_Off_Form_Autocompletion