BTW: IE doesn't do this.
This Firefox bug-report appears to be relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=356097
The "AutoAuth" plug-in referenced toward the bottom of the comments makes the situation slightly more tolerable but does not resolve it.
This comment (#74) toward the end of the bug-report might give a timeline for resolution:
(In reply to comment #73):
> I had a long discussion about this with Boris. They are
considering it but
> maybe it won't be possible to implement until October (when 3.6
comes out which
> contains the fix).
Taking into account that I reported this bug back in October 2006,
I am just
happy this has been tackled and will be implemented in a few
This has clearly been the most annoying bug in FF for me.
Does anyone else have any other input?
I didn't put a server into my firefox network.automatic-ntlm-auth.trusted-uris config setting, I put a domain name.
I.E. tlcapps.com or whatever is relevant.
As a result of whatever decision that was made before my time, the URL does not have a ".com" suffix.
Therefore, the URL for (say) a hypothetical "timekeeper" application would be (say): http://tlcapps/timekeeper/start.cfm.
This is "simply the way it is done around here" for the inward-facing applications.
1 person found this helpful
That is the way it is here as well.
My example was actually a domain called "cps"
It worked for me.
Okay, Ian... please re-cap exactly "what worked for you":
- Are we in agreement that I should be entering "tlcapps" ?
- There appear to be three different configuration-parameters "in play" here ... and although I have not (yet) sought to find documentation for them from the FireFox people, they do appear to have fundamentally different purposes, i.e. "trust" vs. "delegate." Could they conflict in some way?
- The multiplicity of prompts clearly is coming from the <script> tags in the body of the HTML, because I observe that the number of 'extra' prompts is directly related to the number of script-tags that occur. Did the case that you speak of do the same?
- There is a "junk-buster" proxy server living on the local box. (It's the only way I can survive using the Internet these days...) Could this have any relevance?
At this point, I feel like "FireFox thinks it has 'a good reason for asking,' but I don't yet quite know what that 'reason' is."
1) Maybe. In my case we have a local web application that is accessed by typin "CSD" in the url bar. This redirects to a another local domain named "tracker8". That is what I entered into the network.automatic-ntlm-auth.trusted-uris Preference Name in my Firefox config. This worked perfectly for me and I no longer need to login to this application when using Firefox.
2) I don't know about these different parameters. I only knew about the network.automatic-ntlm-auth.trusted-uris one, and it worked for me.
3) Yes, each and every http request the browser makes to a ntlm protected web server needs to be approved, be it html, scripts, css or images.
4) Quite possible. If that proxy server is not allowing the ntlm authentication HTTP requests through or some how monkeying with the domain names being seen by your browser. It could very well be affecting this issue.
P.S. Sorry about the delay in my reply. I was unexpectedly out of the office most of last week.
I found a solution to this problem ... and it is strange ...
(1) It only worked correctly when the only configuration parameter that I filled-out with "tlcapps" was network.automatic-ntlm-auth.trusted-uris. When I included the string into other parameters, it didn't work. (This with or without #2 below.)
(2) I use the "privoxy" proxy on the local-machine, just to keep myself halfway-sane when trying to use the Internet. That proxy does not (yet...) support NTLM correctly. But I could enter "tlcapps" into "No proxy for" (corresponds to network.proxy.no_proxies_on), it magically worked.
Although the latest privoxy 3.0.13 is supposed to handle NTLM, it does not appear to do so yet.