Closed Bug 1569581 Opened 5 years ago Closed 5 years ago

HTTP auth credentials should show httpRealm in about:logins and autocomplete

Categories

(Firefox :: about:logins, defect, P1)

Product:
Firefox
Component:
about:logins
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 70
Tracking Flags:
Tracking Status
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- verified

People

(Reporter: markus.kell.r, Assigned: MattN)

Details

(Whiteboard: [passwords:management] [skyline])

Attachments

(4 files)

Bug 1569581 - Use FxAccountsCommon.FXA_PWDMGR_* constants in AboutProtectionsHandler. r=jaws
47 bytes, text/x-phabricator-request
Details | Review
Bug 1569581 - Show HTTP Auth realm in about:logins and autocomplete. r=jaws
47 bytes, text/x-phabricator-request
Details | Review
Bug 1569581 - Add unit tests for isOriginMatching with null/javascript: origins. r=jaws
47 bytes, text/x-phabricator-request
Details | Review
Result Nightly and Beta
59.48 KB, image/png
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

In Firefox 68.0.1, opened an internal website that is secured by:

1.) HTTP basic authentication:
.htaccess file with:
AuthType basic
AuthName "Secured area"
AuthUserFile /path/to/file
Require valid-user

2.) A login form with user / password fields

Actual results:

  1. "Authentication Required" dialog is shown, prefilled with saved user/password (as expected)
  2. Login form is shown, user field focused, popup list offering two saved logins:
    a) my real user name
    b) the HTTP auth user name

Expected results:

Popup list should only offer saved login for the login form (2.a), but not the HTTP auth user name (2.b).

In the password manager, the HTTP auth entry is rendered as Site: "https://***.***.com (Secured area)". In the autofill popup, the "(Secured area)" is also missing, making that entry even more confusing.

This used to work as expected in Firefox 67. I'm not sure if it got broken in 68.0.0 or 68.0.1.

Seems that creating a test case for this particular scenario is a bit complicated for me and it eats a bit of time that I currently don't have.
Markus, could you perhaps be available to help narrowing down a regression range? You can do this by identifying a good version in which this worked properly - from comment 0 seems that would be 67 then run mozregression1 like this: mozregression --good 67 --bad 69 . Same approach with mozregression GUI version.
Mozregression will download and start builds for you to test given that you have access to the testcase.

status-firefox68: --- → ?
status-firefox69: --- → ?
status-firefox70: --- → ?
Component: Untriaged → Password Manager
Flags: needinfo?(markus.kell.r)
Product: Firefox → Toolkit

It's intentional that we now include HTTP auth results in autocomplete but it's not intentional that you can't differentiate between HTTP auth and form logins. We will add the realm the UI for both the new management UI and autocomplete using a shared helper.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(markus.kell.r)
Priority: -- → P1
Summary: HTTP auth user/password offered as autofill login suggestion → HTTP auth credentials should show httpRealm in about:logins and autocomplete
Whiteboard: [passwords:management] [skyline]
Flags: qe-verify+

It would help having a test page for this scenario. Matt, do you perhaps have one @ ready?

Flags: needinfo?(MattN+bmo)

https://httpbin.org/basic-auth/user/password is a test page for HTTP auth but you would need to have a form login on the same site and I don't know of a site that has both off-hand.

status-firefox68: ? → wontfix
status-firefox69: ? → wontfix
status-firefox70: ? → affected
Flags: needinfo?(MattN+bmo)

Sorry for the late response.

Here's a totally insecure test page:
http://home.datacomm.ch/keller.markus/secured/login.html

First stage (HTTP auth) uses credentials usr/pwd
Second stage (login.html) accepts anything you enter.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #2)

It's intentional that we now include HTTP auth results in autocomplete but it's not intentional that you can't differentiate between HTTP auth and form logins. We will add the realm the UI for both the new management UI and autocomplete using a shared helper.

Identifying the inapplicable login is better than nothing, but I don't see why it would make sense to show a saved login in a context where it is certainly not applicable.

(In reply to Markus Keller from comment #5)

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #2)

It's intentional that we now include HTTP auth results in autocomplete but it's not intentional that you can't differentiate between HTTP auth and form logins. We will add the realm the UI for both the new management UI and autocomplete using a shared helper.

Identifying the inapplicable login is better than nothing, but I don't see why it would make sense to show a saved login in a context where it is certainly not applicable.

The reason is because sites change. I know of applications (one of the biggest payroll providers in the U.S.) that have switched from HTTP auth to form auth (sometimes varying based upon the login URL used) and having convenient access to your relevant logins is something we are trying to improve the last while.

The reason is because sites change.

Fair enough. However, those additional logins should only be shown as secondary items in the autocompletion popup, after the real matches. And they should not block autofill.

My real-life scenario adapted to comment 5:

  • httpauth works fine (usr/pwd is pre-filled)
  • HTML form has saved username zzz

In the past, the HTML form on the login page was already filled with zzz and the saved password.

Now, the HTML form is not pre-filled any more, and I have to remember that I have to select the second entry in the autocomplete popup. That's too much work for something that used to go smoothly before.

Hmm… I'll try fix that as I thought it was supposed to work that way.

Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED

(In reply to Markus Keller from comment #7)

The reason is because sites change.

Fair enough. However, those additional logins should only be shown as secondary items in the autocompletion popup, after the real matches. And they should not block autofill.

My real-life scenario adapted to comment 5:

  • httpauth works fine (usr/pwd is pre-filled)
  • HTML form has saved username zzz

In the past, the HTML form on the login page was already filled with zzz and the saved password.

Now, the HTML form is not pre-filled any more, and I have to remember that I have to select the second entry in the autocomplete popup. That's too much work for something that used to go smoothly before.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #8)

Hmm… I'll try fix that as I thought it was supposed to work that way.

I cannot reproduce this issue. Can you file a separate bug and include password manager debug logging?

Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/980221f42586
Use FxAccountsCommon.FXA_PWDMGR_* constants in AboutProtectionsHandler. r=jaws
https://hg.mozilla.org/integration/autoland/rev/7e2df056a778
Show HTTP Auth realm in about:logins and autocomplete. r=jaws
https://hg.mozilla.org/integration/autoland/rev/a8dc5f13dfcf
Add unit tests for isOriginMatching with null/javascript: origins. r=jaws
Flags: needinfo?(MattN+bmo)
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/88a9bc458456
Use FxAccountsCommon.FXA_PWDMGR_* constants in AboutProtectionsHandler. r=jaws
https://hg.mozilla.org/integration/autoland/rev/2a66b79c7085
Show HTTP Auth realm in about:logins and autocomplete. r=jaws
https://hg.mozilla.org/integration/autoland/rev/9c3b3043ddc7
Add unit tests for isOriginMatching with null/javascript: origins. r=jaws
Flags: needinfo?(MattN+bmo)
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/6652880b0c8a
Use FxAccountsCommon.FXA_PWDMGR_* constants in AboutProtectionsHandler. r=jaws
https://hg.mozilla.org/integration/autoland/rev/f33e5bdffd68
Show HTTP Auth realm in about:logins and autocomplete. r=jaws
https://hg.mozilla.org/integration/autoland/rev/d94f2a6d5771
Add unit tests for isOriginMatching with null/javascript: origins. r=jaws

In order to verify this, QA still needs a testcase for this scenario. I guess one way to go at it would be to ask Markus to check the behavior after the fixed landed: Markus, could you please find time to check what the behavior is now on beta70?
I also would like to have a reduced testcase for this scenario: MattN, anything you can think of that can be cooked up without time invested in setup.

Flags: qe-verify?
Flags: qe-verify+
Flags: needinfo?(markus.kell.r)
Flags: needinfo?(MattN+bmo)

Steps to reproduce in Firefox 69.0:

  1. new profile, all defaults, no passwords stored for home.datacomm.ch
  2. go to http://home.datacomm.ch/keller.markus/secured/login.html
    -> dialog "Authentication Required" shows up
  3. enter User name: "usr", Password: "pwd", press Enter
    -> dialog asks to save login
  4. click Save
  5. enter Username: "zzz", Password: "pazz", press Enter
    -> dialog asks to save login
  6. click Save
  7. go to http://home.datacomm.ch/keller.markus/secured/login.html again (e.g. Cmd/Ctrl+L, Enter). Don't use browser history, refresh, or link to go back.
    -> page is shown without login credentials pre-filled
    -> expected: zzz and pazz should be pre-filled
  8. click into the Username input field
    -> 2 logins "usr" and "zzz" are presented
    -> expected: "zzz" should be first. "usr" should tell that it's from another context, e.g. by appending " (Secured area (hint: usr/pwd))" as in the "Saved Logins" dialog

I'll try to find some time to test 70-nightly later.

Flags: needinfo?(markus.kell.r)
  1. go to http://home.datacomm.ch/keller.markus/secured/login.html again (e.g. Cmd/Ctrl+L, Enter). Don't use browser history, refresh, or link to go back.

I've fixed the success.html page, so you can now click the "Login again" link there, which takes you back to http://home.datacomm.ch/keller.markus/secured/login.html

Testing on a Mac:

Firefox beta 70.0b3 has only improved the sorting in the auto-completion drop-down (step 8 from comment 20).
Still no
a) pre-fill of the form input field
b) rendering of the auth realm in the auto-completion drop-down

Firefox Nightly 71.0a1 has fixed b), but the realm name is severely cut everywhere:

  • in the drop-down, it shows:
    home.datacomm.com (Secured...
  • when I click "View Saved Logins", the new Lockwise page opens, where the list on the left shows a few more characters:
    home.datacomm.com (Secured are...
  • when I click the entry in the list, the title on the right reads:
    home.datacomm.ch (Secured area (hint: ...
  • when I click "Edit", it shows:
    home.datacomm.ch (Secured area (hint: usr/p ...

The only way I found to reveal the whole text is to triple-click the title and copy. Then the clipboard contains the full:
home.datacomm.ch (Secured area (hint: usr/pwd))

Thanks Markus for providing the detailed steps and testcase! I've check out both latest Nightly 71 and Beta 70 and got the following results:

Nightly 71:
(In reply to Markus Keller from comment #20)

  1. go to http://home.datacomm.ch/keller.markus/secured/login.html again (e.g. Cmd/Ctrl+L, Enter). Don't use browser history, refresh, or link to go back.
    -> page is shown without login credentials pre-filled
    -> expected: zzz and pazz should be pre-filled
  2. click into the Username input field
    -> 2 logins "usr" and "zzz" are presented
    -> expected: "zzz" should be first. "usr" should tell that it's from another context, e.g. by appending " (Secured area (hint: usr/pwd))" as in the "Saved Logins" dialog
  • The fields are NOT pre-filled with "zzz" and "pazz" <- Fails expected result
  • "zzz" is displayed first in the dropdown and "usr" has the (Secured area (hint: usr/pwd)) mention, check attached file. <- Passed expected result

Beta 70.0b3:

  • The fields are NOT pre-filled with "zzz" and "pazz" <- Failed
  • "zzz" is displayed as first but the saved credentials don't have their origin displayed in the dropdown <- Failed
    Secure entry in about:logins will have the "(Secured area (hint: usr/pwd))" in the entry title

If you test it again, let us know if there are different results or any other notes. Meanwhile, leaving the NI? for Matt to check the results.

Attached image Result Nightly and Beta —

Guess we worked on this in the same time ¯_(ツ)_/¯
I also agree with the notice about the cut realm name.
Attaching picture for results.

Oh yes, I only fixed showing the domain in the autocomplete popup when subdomain support was enabled and that's only enabled on Nightly so that's why Beta 70 still doesn't show the realm. I guess we need a new bug for fixing this in non-Nightly.

We don't automatically fill login fields over http: so the test cases are not valid for testing that. If you enable the debug logging you will see this:

LoginManagerContent: not filling form since it's insecure

If you test with https: you will get the expected result in Nightly:

  1. new profile, all defaults, no passwords stored for *.mattn.ca
  2. go to https://bugs.mattn.ca/pwmgr/basic-auth/
    -> dialog "Authentication Required" shows up
  3. enter User name: "user", Password: "password", press Enter
    -> dialog asks to save login
  4. click Save
  5. Load https://bugs.mattn.ca/pwmgr/login_and_change_form.html
  6. In registration form enter Username: "zzz", Password: "pazz", press Enter
    -> dialog asks to save login
  7. click Save
  8. go to https://bugs.mattn.ca/pwmgr/login_and_change_form.html again (e.g. Cmd/Ctrl+L, Enter). Don't use browser history, refresh, or link to go back.
    -> page is shown WITH form login credentials pre-filled into the login forms (not registration)
  9. click into the Username input field
    -> 2 logins "user" and "zzz" are presented
    -> expected: "zzz" should be first. "user" should tell that it's from another context, e.g. by appending " (Basic Auth)" as in the "Saved Logins" dialog
Flags: needinfo?(MattN+bmo)

(In reply to Timea Babos from comment #24)

I also agree with the notice about the cut realm name.

Filed follow-up bug 1579738 for that.

Thanks for the answer Matt, re-checked it on latest Nightly and Beta using the steps and testcases from your comment and it works fine.
Do you need a bug submitted for enabling the subdomain in the autocomplete pop-up for non-Nightly builds?

Closing this as Verified - fixed on latest Beta 70.0b4 (64-bit), the follow-up bugs will be handled separately.

Status: RESOLVED → VERIFIED
status-firefox70: fixed → verified
Flags: qe-verify? → needinfo?(MattN+bmo)

(In reply to Timea Babos from comment #27)

Thanks for the answer Matt, re-checked it on latest Nightly and Beta using the steps and testcases from your comment and it works fine.

Thanks

Do you need a bug submitted for enabling the subdomain in the autocomplete pop-up for non-Nightly builds?

No, that is bug 1563330.

Flags: needinfo?(MattN+bmo)
Component: Password Manager → about:logins
Product: Toolkit → Firefox
Target Milestone: mozilla70 → Firefox 70
Version: 68 Branch → unspecified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: