PasswordItem and Saved Passwords

[stonebranch2]

Is there any way to prevent a browser from auto-filling a user name and password field on a form?

SmartClient Version: v9.1p_2014-05-19/Pro Deployment (built 2014-05-19)

Browser: Safari Version 6.1.3 (8537.75.14)

[Isomorphic]

SmartClient / SmartGWT forms' TextItem and PasswordItem default to writing out the HTML attribute autocomplete=off - the standard way to disable browser auto-fill.

Recently some browser developers have made an intentional choice to ignore this setting for forms containing username / password items (essentially for log-in forms).
You can find a couple of blog posts online discussing the logic behind the change in approach - for example here and here.
In essence the idea is that password managers within browsers make it simpler for users to adopt complex passwords which differ across sites by automatically managing them in a secure way, and some browser developers feel this trumps website design considerations.

So now default username/password autofill behavior varies by browser and there is not standard simple HTML way to disable the behavior entirely.
If you want to force the values to be empty, you could explicitly clear, or set the values after drawing the form.

Regards
Isomorphic Software

[stonebranch2]

Thanks for the explanation and reference links.

In my situation, the particular form being populated with a saved user name/password is not a login form.

During login in Safari, if you elect to save the user name/password from the simple HTML login form, and then continue with the scenario below, ...

We have a master/detail panel, and as an administrator clicks through each User in the list, the user name/password field of each User definition form changes to the saved one. Effectively, the User definition form always displays as if it were the record for the same "saved" User and the only indication it is not is the fact Safari yellows out the fields it modifies.

I was surprised that the values from the record being edited in the form were being replaced here.

[Isomorphic]

Hmm that sounds like a confusing user experience certainly.

Just to clarify - are you saying that in Safari you're finding that the browser is auto-populating the username/password field of your form within the application and ignoring your programmatic calls to "setValues()" (or similar) on the form - so refusing to change the value to match whatever record the user selected?

Could you show us your DynamicForm definition, and the code you're using to attempt to set values (which is being ignored)?

Thanks
Isomorphic Software

[stonebranch2]

Yes, Safari is auto-populating the username/password field on our form within the application.

To set the values we use ValuesManager.editRecord(Record).

When clicking on a User record from the list grid, you can see the real user name get populated into the User form and then quickly replaced by Safari and the field becomes yellow.

Is that enough information to go on or do you still want a working example that demonstrates this.

[Isomorphic]

We'll experiment on our end and let you know if we need more information.

One note- we certainly plan to investigate this and find out exactly what's happening. However, regardless of the outcome, it may be the case that the solution here is to ultimately rethink your User Interface.

From your description, it sounds like you have an administrator who is viewing a form with username / passwords of various user-accounts.

It seems like a password item may not make much sense here as a UI choice.

If the admin-user is intended to be able to see and modify the password, it might make sense to display it in plain text.

If the admin-user is not intended to be able to see and modify the password, you may want to suppress the field altogether.

In fact, if you're really trying to hide the existing password value from the administrator, it probably should never be streamed to the client as part of the record - a savvy user could use JavaScript to access the value even if it's being displayed as a row of stars in a PasswordItem interface.

If you did this, you could still allow an admin to reset the value -- the field could be excluded from your dataSource fetch, but you could provide an interface like a "Change Password" button or link which, when clicked, shows the PasswordItem. At this stage if the PasswordItem did autopopulate, it would probably be obvious to the admin-user what happened.


Anyway - we're going to try to reproduce your issue on our end and we'll let you know what we find.

Regards
Isomorphic Software

[stonebranch2]

"If the admin-user is intended to be able to see and modify the password, it might make sense to display it in plain text."

-The administrator is not intended to see it, but can reset it by entering a new password.

"If the admin-user is not intended to be able to see and modify the password, you may want to suppress the field altogether."

-The field is displayed to allow the administrator to reset the password as described above.

"In fact, if you're really trying to hide the existing password value from the administrator, it probably should never be streamed to the client as part of the record - a savvy user could use JavaScript to access the value even if it's being displayed as a row of stars in a PasswordItem interface."

-We DO NOT send any passwords to the client (browser), so there is no way for a savvy user to access an existing user's password from this form. However, we still want the administrator to be able to reset the password from here, and when entering the password, we prefer it to remain masked.

"If you did this, you could still allow an admin to reset the value -- the field could be excluded from your dataSource fetch, but you could provide an interface like a "Change Password" button or link which, when clicked, shows the PasswordItem. At this stage if the PasswordItem did autopopulate, it would probably be obvious to the admin-user what happened."

-We do have a "Change Password" interface that any user can utilize to reset their own password, so certainly we could adapt this to allow an administrator to select a specific user and reset that user's password, however, we would still like to keep the reset capability directly on the form. Furthermore, the auto-populate on the "Change Password" form is still likely to cause some confusion.

As a workaround, I followed a suggestion I found to add a fake username field and password field to the top of the form before the real fields, for example.

TextItem userNameFake = new TextItem("user_name_fake");
PasswordItem userPwdFake = new PasswordItem("user_password_fake");

With them visible, this seems to be preventing Safari from autofilling the real username and password.

The only problem is they cannot be hidden, so using a HiddenItem or setAttribute("editorType", "HiddenItem") will not work, nor will setting them visible:false.

I need a way to add them to the top of the form without them being visible, and avoiding any visual impacts to the form, which I have not discovered yet. Any thoughts?

If you discover anything in your findings that would be more elegant, please do let me know.

Thanks

[Isomorphic]

We're still looking into this issue and seeing if there's a way to avoid this with a framework change. The standard things we'd expect to work, like providing a different name for the form and items, have no impact.

If your "real" login form is on a separate page, it might be simplest to have a separate HTML login page which shows only the login form, and then load the bulk of your app on the main page, which is at a different URL, so would not be expected to pick up the saved auto-complete values.

Alternatively, a workaround for your existing setup would be to have a visible form containing containing a text item and a select item be drawn positioned off screen.

So when you create the edit form, you'd do something like this:

  DynamicForm autoCompleteSink = new DynamicForm();
  autoCompleteSink.setItems(
    new TextItem("name"),
    new PasswordItem("pwd")
  );
  autoCompleteSink.setTop(-1000);
  autoCompleteSink.draw();
  
  ... // Subsequent code would define and draw you're actual edit form

Obviously this isn't elegant and we're hacking around a native browser behavior, but, provided the "sink" form is drawn first, the browser will auto-fill it and not your edit form.

We'll let you know if we come up with a neater solution for this at the framework level.

Regards
Isomorphic Software

[stonebranch2]

Thank you, I will give the workaround a try.

[bwilkins30]

If the password is saved after first login and then you turn autocomplete = off after that fact, the form might be autopopulated in some browsers. Firefox will be following IE11's lead and ignore autocomplete = off for passwords (it can be reverted with an autoconfig setting), see here: https://bugzilla.mozilla.org/show_bug.cgi?id=956906. Like Isomorphic said, a lot of banks are separating the login page from the password page.

[andyx1975]

So I guess the easiest way will be to create a new index.html page, which opens your host html page in a new Frame... this worked for me.

Code for index.html page:

<frameset rows="100%">
  <frameset cols="100%">
    <frame src="YOUR.LOGIN.PAGE.HTML" frameborder="0" scrolling="yes">
  </frameset>
</frameset>

When you call now the index.html page, chrome does not recognize that you are using password fields. If you call the host page "YOUR.LOGIN.PAGE.HTML", it does recognize the password fields.

[mazzi]

Hi,

I haven't seen any update on this thread in a while. So first. I would like to ask the obvious question of whether there has been a framework change, as mentioned above, to properly address this browser behavior. If so, would someone pointing me in the right direction of how to apply this framework change in my SmartGWT app. I would really appreciate it. If on the other hand no framework change was made then what the recommended SmartGWT workaround for addressing this behavior. Google seems to suggest in the bug report regarding this issue, which can be found here: https://bugs.chromium.org/p/chromium...id=468153#c164 to give semantic meanings to the autocomplete attribute values beyond the OFF value, such as autocomplete="new-user-street-address". Does anybody know how to that for Smartgwt form items?
We're really stuck with this one. Any help would be greatly appreciated.

Thanks,
Mike