[IMPORTANT] Changing the look of your login

tl;dr
Today (21 FEB 2018 at 7am PST) the login window to most Mozilla sites will change. This New Login Experience is:

  • Faster
  • More secure
  • More efficient

Longer version
The IAM Project has redesigned the login to Mozilla websites from scratch and implemented a New Login Experience with the following core capabilities:

  • Auto login: If you are already authenticated with Mozilla IAM, we will log you in automatically (i.e. no more “Last time you logged in with” prompt).
  • Login method detection: You provide an email address, and we know whether this is an LDAP or email login.
  • Optimized experience: We built a number of small things into the New Login Experience to make it convenient to use. This includes screen reader compatibility, keyboard navigation, and password manager compatibility.
  • More secure: We have upgraded to the latest versions of supporting software libraries.

We hope you enjoy your future logins as much as we enjoyed building this new experience. We are still actively testing the experience (including additional user testing in the coming week) to fine tune the experience and ensure login is fast, secure and efficient. Given this, we welcome your feedback, comments and questions in our IAM Discourse category.

Best regards,

Jeff and Henrik on behalf of the IAM Project Team

PS: For Frequently Asked Questions (FAQs) please see http://bit.ly/iam-nlx-faq.

9 Likes

After submitting my (LDAP) password in the New Login Experience, the authentication process stalls. I see a animated throbber along with the name of the site I’m attempting to access, but I never reach that site. And if I load the site again, I’m not signed into it.

That happens for multiple sites I’ve tried to access this morning, including this one! Fortunately, I found a container in which I’m already signed into this site, so I’m able to post this topic.

We’re currently debugging this, stay tuned!

edit: In the meantime we’ve reverted back to the old login.

1 Like

(This is a minor issue, but presumably still relevant, given that the new experience intends to work well with password managers.)

Upon being prompted for my email address, if I tell 1Password to auto-fill the form, it successfully enters my (LDAP) email address, and the email address field has focus, so I can “submit” the form successfully by hitting the Return key on my keyboard, at which point the password field appears, is also auto-filled with my password, and has focus. So far, so good.

However, if I then press the Return key, nothing happens, and the form doesn’t get submitted. I have to either click the form submission button manually or tab to it and hit the Return key to submit the form.

Given that the password field is focused, and my password is filled in, I would expect to be able to hit the Return key to submit the form.

1 Like

Thanks @mykmelez for reporting this. I have filed a bug for myself to fix it. In the mean time please use the TAB key to get to the submit.

Is it just me, or does it feel like there are more clicks to get where you want to be now on initial login?
After the initial login it does seem there are much less clicks to get where you want to be, so overall the experience is really smooth.

Thanks for paying attention to the small UX things. I’d appreciate if you’d also remove this redundant click that the login always needs me to do when using 2FA. I use Google Authenticator for 2FA, and it has me click on this button to reveal the passcode form, which is a bit silly since it’s the only choice of action I have on the screen.

2018-02-21%2009_25_08-Start

@brianpeiris Indeed, this is a problem with Duo’s web interface that has existed since we started using them (not connected to the move to the new login experience launched today). To fix this will require building our own Duo interface which we’ve talked about but isn’t scoped yet.

4 Likes

Maybe my experience is unique, this new UX doesn’t feel more efficient.

For initial login extra interaction with the page on initial login (clicking/enter/tab+enter) between username and password.

And now every time I go to an app another Mozilla provided app that auths with Auth0, I find myself doing one of two things:
Going through the same process as initial login minus Duo. (First use of a given app after 2FA)
or
Starting to enter my username in the field when the page (like the initial login) then refreshes to the app. (any subsequent use of the same given app)

The latter of the two is worry some as I found my creds getting imputed onto the refreshed page because I click my password manager just after the login page is wiped and the app page starts loading.

But neither feel like “auto login” (even if the second actually does get you there if you wait for a moment). Previous behavior I clicked the button with my login name on the “Last time you logged in with…” prompt, which I didn’t mind… it was like a confirmation that I was proceeding with the correct credentials.

I can happy try to capture a video of either. Both happen in FF 58.0.2 on macOS 10.13.3. Have not tried a different browser.

Side note: I am not a fan of hidden input fields. (ie the way you or your password manager can input your password in a field before it was visible). Didn’t like it when Google started doing this to their login page either.

Hi @johnb! Thanks for taking the time to give feedback.

With regards to the first issue: are you using the same login methods for these Mozilla-provided apps (i.e. LDAP or GitHub)?

The fact that you see the username field while you are being auto-logged-in is a known bug, this will be fixed in our next release, which will be live next week at the latest. In the fixed version, you will not see the username field while being auto-logged in.

The hidden password field is a UI choice we have made, it is intended to make the experience simpler for people who do not have passwords (i.e. users without LDAP accounts). In most password managers autofill can be turned off, I think even on a per-site basis.

All of mine are LDAP.

Auto login has been pretty smooth, but I’ve had a couple hiccups where it pauses for a few seconds at the login screen before proceeding. When starting a new login session, having to enter my email/username (LDAP) and password on separate screens (even though it gets autofilled by 1PW because it’s a hidden field) is an extra step as compared to before. Out of curiosity/understanding, why did we make that particular change to the login flow? Thanks!

@cbrentano we chose this flow because it allows us to build a “smart” login experience. Upon entering your email in the first screen/card we check if this will be the LDAP login flow or the passwordless email login.

We are thinking of making the flow smarter in the future. You would then enter an email address and we will know to which authentication provider to route you next (LDAP, Github, Google, email).

Hope this explanation makes sense?

1 Like

Yep, thanks @hmitsch! Much appreciated.

2 Likes

To all people in this thread: Many of your comments were addressed in Tuesday’s update to our New Login Experience:

  • return key submits the password (cc @mykmelez)
  • Auto login displays a loading spinner to avoid confusion (cc @johnb)

For more information please read:

1 Like

BUG 1: Infinite loop

  1. Tried to sign-in using GitHub (for the first time);
  2. After being signed in on GitHub, I get this message:

ERROR: You must setup a security device(“MFA”, “2FA”) for your GitHub account in order to access this service.Please follow the GitHub documentation to setup your device, then try logging in again.

  1. I DO NOT want to setup a security device;
  2. I click on “Go Back” to try a different auth mechanism, but I’m being redirected to this error over and over again. I’m stuck. I go to the main page and click on “Sign in”, but I’m being instantly redirected to this ERROR page, with no option to sign-in using email or my Google account - I had to clear all my cookies to get rid off of this looping;
  3. I try again, this time using my Google account, but I get this error:

ERROR: Sorry, you may not login using Google. Please instead always login with GitHub
bug-mozilla-no-google

But I CANNOT log-in with GitHub!

BUG 2: Editor tools don’t work when adding a comment here
When I finally managed to sign-in (using private mode and signing-in using an email account), I can’t comment because the tools (e.g. bold, italic, hyperlink, blockquote, etc) are not “clickable”. When I roll over the mouse it shows me the “select cursor”. It’s like if there’s an invisible text on top of the icons. Weird thing is that it works properly on Chrome.
bug-mozilla-editor

BUG 3: “alert()” doesn’t work in responsive mode
I know this is not the right place to post this bug, but I’m too frustrated and I already wasted too much time trying to log in here. So I’m going to post here in a hope that someone sees this.

The bug:
On Quantum, typing “window.alert(1)” on JS console, while on “responsive mode”, it doesn’t work.

Versions:
FF: Quantum, v. 58.0.2, 64-bit
SO: Ubuntu 17.10, 64-bit

1 Like

@loureiro.rg Thanks for reporting your feedback! I’m afraid I cannot comment on what’s happening in Discourse or Firefox’ responsive mode, but with regards to your first comment: for security reasons, we are forcing users to use their most secure method of logging in, it sounds like this is email or 2FA’d GitHub.

The fact that you cannot always go back after getting this error is an issue we are aware of, we are working on shipping improvements to this in the not too distant future. Please bear with us for this!

1 Like

@leo can you follow-up on Bug 2, please?

1 Like

@loureiro.rg I am checking in with our #devtools team to see if they are aware of Bug 3.

1 Like

@loureiro.rg for Bug 3, there is a bugzilla issue at https://bugzilla.mozilla.org/show_bug.cgi?id=1273997

Hope this helps.
Regards,
Henrik

1 Like