Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accounts UI does not trigger password store/autocomplete in Firefox #1746

Closed
mitar opened this issue Jan 9, 2014 · 14 comments
Closed

Accounts UI does not trigger password store/autocomplete in Firefox #1746

mitar opened this issue Jan 9, 2014 · 14 comments

Comments

@mitar
Copy link
Collaborator

@mitar mitar commented Jan 9, 2014

_1 Upvote_ I just now noticed that Accounts UI does trigger password store/autocomplete in Firefox. As using password managers is a good security practice, I think this should be addressed somehow.

Tested on Firefox 26. Should be probably tested on other browsers as well.

@glasser
Copy link
Member

@glasser glasser commented Jan 15, 2014

Known bug, but worth tracking.

This strategy for login forms means that browsers' "Remember password"

It seems like Chrome is unlikely to ever work without server side rendering.

@JobJob
Copy link

@JobJob JobJob commented Mar 1, 2015

+1

@Obiwarn
Copy link

@Obiwarn Obiwarn commented Mar 4, 2015

This annoys many of my users.
Is there a workaround?

@nkoren
Copy link

@nkoren nkoren commented Apr 11, 2015

FWIW, I built a custom login page not using Accounts-UI -- just a bunch of custom templates -- and it works fine with password managers in all browsers. So server-side rendering doesn't seem to be needed; it's something else that is causing the problem.

@JobJob
Copy link

@JobJob JobJob commented Apr 12, 2015

Also, FWIW, this workaround, while extremely kludgy, seems to work in Firefox, but not Chrome:

<form id="loginform" action="javascript:">
    {{loginButtons}}
</form>

Then somewhere in a js file

Blaze._allowJavascriptUrls() //to allow the action="javascript:" in the <form> element
Template._loginButtonsLoggedOutDropdown.events({
  'click #login-buttons-password': function () {
    $('#loginform').submit()
  },
  'keypress #login-username, keypress #login-email, keypress #login-username-or-email, keypress #login-password, keypress #login-password-again': function (event) {
    if (event.keyCode === 13)     
      $('#loginform').submit()
  }
});

It seems Firefox may need a form element and seems to rely on the submit event in order to ask the user to save a password. @nkoren do you have a form that you submit in your custom login page?

On Chrome I get prompted to save the password if just after logging in I modify a file and there's a hot code push which refreshes the page. Accordingly, if after login you get the browser to reload e.g. by calling location.href = "/logged_in" or similar you can get chrome to prompt to save the password.

Safari seems to work fine without any of this madness :)

@hugoroy
Copy link

@hugoroy hugoroy commented Sep 15, 2015

Sorry if this isn't the right place, but we have this problem on a meteor app as well, tosdr/tosdr2#3 -- is there an official way to work around this bug or is this bug fixed?

Thanks

@pierreozoux
Copy link

@pierreozoux pierreozoux commented Sep 15, 2015

Indeed, it is still an issue.
It is sad because even successful open source projects like https://demo.rocket.chat/home are facing the same issue.
Maybe you use oauth, but email login is still widely used and is good for user's privacy.

Can somebody from meteor team give a status on this? It would be awesome!

@nkoren can you share a code sample please?

@steinmb
Copy link

@steinmb steinmb commented Sep 16, 2015

Still an issue for me also.

System

  • Firefox 40.0.3
  • OS X 10.10.5
@stubailo
Copy link
Contributor

@stubailo stubailo commented Sep 21, 2015

I have been trying to track down the criteria that popular password managers use to identify password forms. Is it the URL? Is it some attributes on the form?

I can't find any documentation on this issue, anything would be super appreciated.

@pierreozoux
Copy link

@pierreozoux pierreozoux commented Sep 21, 2015

@stubailo from earlier comment:

This strategy for login forms means that browsers' "Remember password"

https://gist.github.com/kostiklv/968927

Tell me if you find good ways to make it work :)

@hugoroy
Copy link

@hugoroy hugoroy commented May 20, 2016

Any update on this? @pierreozoux @stubailo

@michielbdejong
Copy link

@michielbdejong michielbdejong commented Dec 22, 2016

I think just adding a form tag around the login form is not enough, probably because it's generated dynamically. One ugly but minimal work-around is to add a 'Remember my password' form in the "not logged in" page, but still use the default login form for actually logging in: https://github.com/tosdr/tosdr2/pull/41/files

If there is really no way to make dynamically generated login forms (like the one Meteor uses) work in Firefox, then this might also be worth submitting a bug to Firefox about this? If I can get some guidance from a Meteor core person about what a desired solution would be, then I could work on that.

@mitar
Copy link
Collaborator Author

@mitar mitar commented Dec 22, 2016

useraccounts do not have this problem and autocomplete works. So I am not sure what is a difference.

@hwillson hwillson self-assigned this Dec 5, 2017
hwillson added a commit to hwillson/meteor that referenced this issue Dec 5, 2017
`accounts-ui-unstyled` currently uses `<div />`'s to hold its
login/signup forms, as well as `<div />`'s to represent the
login/signup buttons in the form. By not using proper
`<form />` and `<button />` elements, certain browser's do not
notice incoming login/signup requests, and therefore do not
trigger their built in "would you like to save your user/password"
functionality. This commit adjusts the `accounts-ui-unstyled`
login/signup form to use proper `<form />` and `<button />`
elements, allowing most (Chrome, Firefox, IE - Safari will
recognize the request when a user attempts to leave the page)
browsers to recognize incoming login/signup requests.

Fixes meteor#1746.
@hwillson
Copy link
Member

@hwillson hwillson commented Dec 5, 2017

I've submitted PR #9442 to help address this.

benjamn added a commit that referenced this issue Dec 13, 2017
* Help browser account saving with accounts-ui login/signup forms

`accounts-ui-unstyled` currently uses `<div />`'s to hold its
login/signup forms, as well as `<div />`'s to represent the
login/signup buttons in the form. By not using proper
`<form />` and `<button />` elements, certain browser's do not
notice incoming login/signup requests, and therefore do not
trigger their built in "would you like to save your user/password"
functionality. This commit adjusts the `accounts-ui-unstyled`
login/signup form to use proper `<form />` and `<button />`
elements, allowing most (Chrome, Firefox, IE - Safari will
recognize the request when a user attempts to leave the page)
browsers to recognize incoming login/signup requests.

Fixes #1746.

* Add History.md entry outlining potential back compat issues

* Bump minor versions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.