NTLM/Negotiate Auth hangs browser
Categories
(Core :: Networking: HTTP, defect, P3)
Tracking
()
People
(Reporter: fb+mozdev, Assigned: valentin)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [necko-triaged])
Attachments
(2 files)
I'm in a corporate environment (with a rather loose proxy). I set up Firefox to automatically login for the intranet pages at intranet.company.tld (address redacted) with the following settings: - network.automatic-ntlm-auth.trusted-uris;.company.tld - network.negotiate-auth.delegation-uris;.company.tld - network.negotiate-auth.trusted-uris;.company.tld When I visit the intranet pages, I experience multiple and multi-second hangs of the browser (including chrome). Maybe it's some synchronous IPC? Interestingly, when I reset network.negotiate-auth.trusted-uris to an empty value, the hangs disappear reproducibly. Fx 55.0.3, e10s running well (5/5 windows, 1/1 content processes). Issue was visible in previous Firefox versions as well. Happy to help you out with logs etc. (esp. of the login process) if you guide me how to acquire them.
![]() |
||
Comment 1•7 years ago
|
||
Thanks for this report and an offer to help. I will then ask you for logs according https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging. Please set the log modules (MOZ_LOG) as: sync,timestamp,nsHttp:5,negotiateauth:5,NTLM:5 Then start Firefox, reproduce the problem only and close it again. It's better to send the log file to my bugzilla email directly than to expose it here. There might be cookies exposed in the log. Thanks!
Comment 3•7 years ago
|
||
This sounds worth fixing, but doesn't sound like a QF bug. --> marking as [qf-] (The QF effort is focused on high-usage websites and high-value benchmarks, and it can't cover all performance problems in Firefox.)
Reporter | ||
Comment 4•7 years ago
|
||
Honza, I'm off for the next two seeks so it'll take a while before I can profile. Ni? me as reminder.
Comment 5•7 years ago
|
||
Bulk priority update: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Updated•7 years ago
|
Updated•7 years ago
|
![]() |
||
Comment 6•7 years ago
|
||
Florian, still there? To move forward it would be great to obtain the log as state in comment 1. W/o it we can only guess what to do and hence de-prioritize this bug. I suspect we need to implement async credentials processing also for the NTLM module (impl nsHttpNTLMAuth::GenerateCredentialsAsync.) But I don't want to shoot into darkness. Thanks!
Reporter | ||
Comment 7•7 years ago
|
||
Yes, sorry, I did not forget about this bug, but was derailed by higher priority work. Plus, my computer crashed, so I need to wait to get it back. I hope to provide the logs by the end of this month. Keeping ni?.
Assignee | ||
Comment 9•5 years ago
|
||
This is blocking socket process, being the last consumer of DeprecatedSyncResolve.
Assignee | ||
Comment 10•3 years ago
|
||
I need to look into how difficult it is to refactor this.
Assignee | ||
Comment 11•3 years ago
|
||
It's not very clear why this bug was happening, but there are two possibilities:
- It was happening because of the call to DeprecatedSyncResolve on the main thread.
- It was happening because of the call to AcquireCredentialsHandleW was taking too long (also on the main thread)
For both of these, the solution would be to implement GenerateCredentialsAsync for nsHttpNTLMAuth.
The simple way to implement it would be to dispatch a task to the background thread that resolves the cname for the host, then calls nsAuthSSPI::Init on the same background thread.
The main problem with this is there is no code coverage for this.
Since this is using the windows SSPI functions, can't really hit this in automation. I've looked into creating a kerberos server in a VM, but it's not trivial. Another approach would be to have a dummy shim for the SecurityFunctionTableW structure for testing.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 12•3 years ago
|
||
Reporter | ||
Comment 14•2 years ago
|
||
Do you still need logs from me?
Comment 15•2 years ago
|
||
(In reply to Florian Bender from comment #14)
Do you still need logs from me?
Yes, I think so. Could you send the log to necko at mozilla dot com
?
Thanks.
Comment 17•1 year ago
|
||
Clear a needinfo that is pending on an inactive user.
Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE
.
For more information, please visit BugBot documentation.
Description
•