From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9+) Gecko/20020327 BuildID: 2002032708 If I try to access any secure site (https://), I get a blank dialog box asking for username and password for my company's proxy. Entering the correct information in this dialog results in the dialog box being re-posted blank even though remember settings was checked. After pressing cancel button, I get a page describing that authentication was not granted. This has happened with several builds since 0.9.9 (all of the ones I have tested). I have no problems when using 0.9.9; the dialog box is prefilled with the correct username and password and pressing the OK button loads the secure site correctly. I can access normal (http://) sites thorugh the proxy with this build of Mozilla and the dialog box is prefilled with my username and password correctly. Reproducible: Always Steps to Reproduce: 1. Enter any address starting with https:// 2. 3. Actual Results: Cannot get through proxy server.
Dupe of bug #127671 ???? whose fix does not seem to work (according to what I read there).
This is still a problem in the 1.0.0 nightly builds. Is there any debug information I can provide to help pinpoint the cause for this problem?
I tried this at work (SSL Proxy w/ auth), on the Mac OS 9 Mozilla 1.0 RC1 final candidate, and it didn't seem to have the problem. I was in a hurry, and need to go back to Windows and look further. What we need here is either a packet trace -or- The proxy type (vendor and version) + log entries of the failure.
How do I perform a packet trace? I have searched through mozilla.org and haven't found an indication as to what tools are required. Is there a way for a user to get the necessary information regarding the proxy server. I work for General Electric and the support group has historically not given any information regarding the network setup, especially regarding "unsupported" software.
I used windump to hopefully get you a useful trace. I will attach the output from windump -vvv. During the session all I did was try to go to a https:// site, enter username and password for the proxy in the dialog and press OK, and then press cancel on the dialog after it reappears.
+ cc: tever I'm actually a bit rusty w/ Windows packet analyzers, so I'm asking Tom to give some input here. We just need to capture the first 8 or so packets, to see what your browser is saying to the proxy server for the "Proxy-Auth" line.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can vie for this bug, as I have the very same problem. I work under Windows 2000 Professional, running Mozilla 1.0RC1. I have the very same problem described below. What I do know is that my company uses Windows ISA for proxy functionality. If I can be of help with further information, please contact me.
This problem also exists under linux since mozilla builds in late march. I also could reproduce this phenomenon under Win2k. Even now the problem persists (20020504).
Does anyone know what kind of proxy server they are connecting to?
I know that I'm connecting to a Microsoft ISA server.
Keywords: mozilla1.1, regression
Summary: Can not get proxy authentication when accessing https:// sites → Cannot get proxy authentication when accessing https:// sites
Summary: Cannot get proxy authentication when accessing https:// sites → Proxy:authentication when accessing https:// sites
Summary: Proxy:authentication when accessing https:// sites → Proxy:authentication when accessing https:// sites via ISA
I thought this might be NTLM related, but http: proxy is working w/ auth... I recall minor problems with HTPP proxy + auth, which should have all gone away by now. A Mozilla 1.1 or 1.2a update would be appreciated.
Summary: Proxy:authentication when accessing https:// sites via ISA → Proxy: authentication when accessing https:// sites via MS ISA
I can confirm that the behaviour is indeed fixed in Mozilla 1.1. At least the sites I had problems with all behave correctly now. Thanks!
Marking works for me based on comment 14. Reopen if there are still problems with recent nightly builds.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.