Closed Bug 1611744 Opened 6 months ago Closed 4 months ago

Requires a proxy password, even if it is saved

Categories

(Core :: Networking: HTTP, defect, P2)

71 Branch
Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla77
Tracking Status
firefox-esr68 --- verified
firefox75 --- wontfix
firefox76 --- verified
firefox77 --- verified

People

(Reporter: mozilla.org, Assigned: mkaply)

References

(Depends on 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

Attached image Screenshot_145.png

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

Steps to reproduce:

network.automatic-ntlm-auth.allow-proxies true
network.negotiate-auth.allow-proxies true
signon.autologin.proxy true

Actual results:

  1. On CentOS 8 run Firefox 68.2.Oesr (64-bit).
  2. I set proxy server for all protocols.
  3. Shut down this firefox.
  4. Run this Firefox.
  5. Enter the password to connect to the proxy server. I check the "save password" checkbox.
  6. Shut down this firefox.
  7. Run this Firefox.
  8. Enter the password to connect to the proxy server. I check the "save password" checkbox.
  9. In cycle again point number 3.

Expected results:

  1. On CentOS 8 run Firefox 68.2.Oesr (64-bit).
  2. I set proxy server for all protocols.
  3. Shut down this firefox.
  4. Run this Firefox.
  5. Enter the password to connect to the proxy server. I check the "save password" checkbox.
  6. Shut down this firefox.
  7. Run this Firefox.
  8. The proxy will be connected without retrying the login authentication window. The username and password are pre-filled.
  9. Shut down this firefox.
  10. Run this Firefox with automatic proxy auth (without logging in again).

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Password Manager
Product: Firefox → Toolkit

The priority flag is not set for this bug.
:MattN, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(MattN+bmo)
Priority: -- → P2

Honza, this looks similar to bug 1548804. Can you have a look at it?

Component: Password Manager → Networking: HTTP
Flags: needinfo?(honzab.moz)
Product: Toolkit → Core
Whiteboard: [necko-triaged]
Status: UNCONFIRMED → RESOLVED
Closed: 5 months ago
Flags: needinfo?(honzab.moz)
Resolution: --- → DUPLICATE
Duplicate of bug: proxy-save-password
Flags: needinfo?(MattN+bmo)

This is not a duplicate bug to bug number 1446265.

This bug fixes that the authentication form does not have a checkbox to store the password.

While my bug is about something completely different, on my screenshot I even see this checkbox.

This bug is not duplicate.

Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Confirming and taking.

Even though the password is saved (and prefilled in), the login dialog appears at every startup. I'll take a look.

Assignee: nobody → mozilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

So the core problem here is that when the initial prompt comes up, it doesn't have a window associated with it, so we can't get the private browsing status of that window. We end up in this code:

https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm#341

which returns true for inPrivateBrowsing if we don't have a window.

There have been a couple of bugs that have touched this over the years, like bug 1301109, bug 723004, so it's difficult to tell what the root cause was. Some guesses are:

  1. Move to private windows versus overall private status.
  2. Some network request moved earlier in startup.

My initial thought is to remove the privateWindow check for proxy autologin. If a proxy has been configured by Firefox, the user would want to use it regardless of private mode or non private mode (and they can't store a different proxy login for private versus non private)

Depends on: 1630787
Duplicate of this bug: 1449867

For posterity, I was able to test this on Windows by installing Squid Proxy and then setting up simple auth by adding a .htpasswd in etc

admin:$apr1$kWA/DRFy$klaeXRe3S3jIPqc64HTMA0

(admin/1234)

and adding this at the top of squid.conf

auth_param basic program "/cygdrive/c/squid/lib/squid/basic_ncsa_auth.exe" "/cygdrive/c/squid/etc/.htpasswd"
acl ncsa_users proxy_auth REQUIRED
http_access allow ncsa_users

Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/fefd58baecf9
Use permanent private browsing state for autologin, not per window. r=MattN
Status: ASSIGNED → RESOLVED
Closed: 5 months ago4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

Comment on attachment 9141759 [details]
Bug 1611744 - Use permanent private browsing state for autologin, not per window. r?MattN

Beta/Release Uplift Approval Request

  • User impact if declined: Users that have saved proxy password still get asked to login at every startup.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Setup a proxy with a user/pass. Verify that when you save the password and check the "don't ask for password if saved for proxy" in preferences is checked. Verify you autologin.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Very specific case around proxy password.
  • String changes made/needed:

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Common enterprise case (proxies)
  • User impact if declined: Users that have saved proxy password still get asked to login at every startup.
  • Fix Landed on Version: 77
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Very specific case around proxy password.
  • String or UUID changes made by this patch:
Attachment #9141759 - Flags: approval-mozilla-esr68?
Attachment #9141759 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9141759 [details]
Bug 1611744 - Use permanent private browsing state for autologin, not per window. r?MattN

Avoid spurious login prompts for users with saved proxy passwords. Approved for 76.0b8 and 68.8esr.

Attachment #9141759 - Flags: approval-mozilla-esr68?
Attachment #9141759 - Flags: approval-mozilla-esr68+
Attachment #9141759 - Flags: approval-mozilla-beta?
Attachment #9141759 - Flags: approval-mozilla-beta+

(In reply to Mike Kaply [:mkaply] from comment #13)

  • User impact if declined: Users that have saved proxy password still get asked to login at every startup.

To clarify in case this goes in any release notes, the problem is that we weren't honoring the "Do not prompt for authentication if password is saved" checkbox in proxy settings.

QA Whiteboard: [qa-triaged]

Kaply, can you explain how step 2 should be done exactly? (setting proxy server for all protocols)
I have to mention that we have a proxy account, but I don't know how to use this info. These are the notes (not username and password):

191.101.148.91
Use for all your proxies
ports http/https 45785
or
socks5 45786) 

Maybe even modifying the steps to reproduce if you think verification should be performed any other way.
Thank you!

Unless you have a proxy that requires a userid/password, you can't recreate/test this problem.

A far as setting proxy server, it's just a mater of putting the proxy info in Network Settings for HTTP Proxy and then checking the box that says "use this proxy for all protocols"

I have a proxy that has a userid and password, I just left the userid and password out of the comment because it's a paid proxy. The problem is that I don't know how to set it up correctly (or for this issue specifically, to "sett the proxy server for all protocols", as required in comment 0, step 2.).
While attempting to figure out how to set it up, I figured out that I have to check the "Also use this proxy for FTP and HTTPS" checkbox so that the same IP is used for the HTTPS and FTP fields, for this test.

I have reproduced this issue on Release v75.0 and verified the fix on Nightly v77.0a1 from 2020-04-27 and Beta v76.0 (RC). Unfortunately, this fix is not yet in the latest ESR v68.7.0esr, but it will be verified when the next ESR is released. Verification made on Windows10 and Ubuntu 18.

OS: Unspecified → All
Hardware: Unspecified → Desktop

NI to myself as a reminder.

Flags: needinfo?(daniel.bodea)

Also verified on ESR Candidate v68.8.0esr.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(daniel.bodea)
You need to log in before you can comment on or make changes to this bug.