The default bug view has changed. See this FAQ.

Proxy Authentication required while typing Search String

RESOLVED FIXED in Firefox 23

Status

()

Firefox
Search
RESOLVED FIXED
10 years ago
4 years ago

People

(Reporter: Prashant Mahajan, Assigned: Gavin)

Tracking

unspecified
Firefox 23
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Steps:
1. Start a new instance of Firefox.
2. Enter any search String.

Problem: The Proxy Authentication dialog comes in between (Before the user could click the Search button)and the search string is  entered in the User name, since the user like me is watching the keyboard.

Reproducible: Always

Steps to Reproduce:
Steps:
1. Start a new instance of Firefox.
2. Enter any search String.

Problem: The Proxy Authentication dialog comes in between (Before the user could click the Search button)and the search string is  entered in the User name, since the user like me is watching the keyboard.
Actual Results:  
Problem: The Proxy Authentication dialog comes in between (Before the user could click the Search button)and the search string is  entered in the User name, since the user like me is watching the keyboard.

Expected Results:  
The Proxy authentication should have come after the user had written the search query.

Comment 1

8 years ago
We have exactly the same Problem in Corporate. But not always. I cant describe what to do, to enforce this behavior. But ALWAYS Firefox need to type username and password, by starting it, for ALL Tabs which should be opened behind proxy (squid). The only workaround to "solve" the problem is, to start Firefox with only 1 Tab. And THEN the problem with the search string doesnt appear! Apart from that its very hard going to start FF with many Tabs using a Proxy!

Manfred

Comment 2

8 years ago
Confirmed on Firefox 3.0.11 - Firefox 3.5.1 and Minefield/3.6a1pre (on Windows
XP Pro SP3).
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

8 years ago
Blocks: 484934
No longer blocks: 484934
Duplicate of this bug: 484934
Duplicate of this bug: 407723

Comment 5

7 years ago
Confirmed in
Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Comment 6

7 years ago
I should add that I would expect Firefox to show the proxy authentication dialog only once, at the beginning, when entering the first letter of the search string.

FF actually opens a connection to the search engine when typing the search query, so a proxy authentication is required here. I believe the error is that it doesn't cache the authentication information given there.

Workaround: Open any page in FF and authenticate accessing this web page. Then the authentication information given there is stored in the current FF session. After that you can enter a search term as usual. FF will use the stored authentication information to access the search engine then.

Comment 7

7 years ago
Confirmed also in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729)

A complementary note about this issue:

It seems that actually firefox does not cache the credentials at all when the proxy authentication box is triggered from the Search bar.
Indeed, if you were not yet authenticated and you type something is the ssearch bar, you will be prompted for your username & pwd; if after authentifying yourself, you add other characters to the search string, the authentication box will be prompted again.
This until you open any webpage that requires proxy authentication and authenticate yourself (in which case credentials are saved and available for the search bar too)

Updated

7 years ago
Duplicate of this bug: 538953

Comment 9

7 years ago
Bug 538953 comment 7 with attachment 425220 [details] has an HTTP log where the prompt shows for keypresses, 3 times, even though the password is given each time.
Attachment 425394 [details] has another, saying "In the search bar the letter "a" was pressed 3 times. After 4 login's all work fine."
Duplicate of this bug: 605390

Updated

6 years ago
Duplicate of this bug: 627294

Comment 12

6 years ago
We sniffed network-traffic on a Client and saw that there was no login information beeing sent to the TMG-Proxy between typing the searchstring. Obviously this is the reason for not beeing authenticated with the TMG.

Firefox 4.0.1
Forefront TMG 2010

Comment 13

5 years ago
This bug still exists in FF 10.01 - in fact it's been there ever since the search bar first appeared in Firefox. It happens on both Windows & Linux platforms (I've never tried osx) and is extremely annoying and confusing for users who don't understand what is happening as it repeatedly prompts the user to login as they try to type in a search term.

Comment 14

5 years ago
This bug still exists in FF 11.0 - fully agree to Ian

Comment 15

4 years ago
Confirmed in FF 18.0
SQUID 2.7.9 with NTLM authorization.
Duplicate of this bug: 831175
Is anyone CCed here still able to reproduce this problem? I have a potential patch to fix it, but I can't easily reproduce the problem to fix it. If anyone is willing to help test a patched build, please let me know.
Created attachment 724651 [details] [diff] [review]
potential patch

Comment 19

4 years ago
I've moved to using a transparent NTLM proxy server, but our basic authentication server is still alive, and I can easily test with it. What I can't do right now is build Firefox, unfortunately.

Comment 20

4 years ago
Gavin, might this be fixed by bug 521467, maybe this is why you can't reproduce?
Joshua: that's great - assuming you can still reproduce the problem in a build of Firefox Nightly (https://nightly.mozilla.org/), I can link you to a build with my patch that you can compare it to. Which platform do you need?

Ben: I haven't reproduced locally because I don't have a proxy configured.

Comment 22

4 years ago
I was experiencing this bug a long time ago,
disabled the "show suggestion" at the time, never reactivated it since.

I just reactivated it : it seems definitively FIXED ;-)

Comment 23

4 years ago
Testing on Linux using ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-21.0a1.en-US.linux-x86_64.tar.bz2   I can still reproduce the problem;   start up firefox,  start typing and proxy auth dialog comes up after the first character,  fill in login details and type next character and prompt comes up again etc    

I'm happy to test Gavin's patch,   Gavin if you have a Linux 64bit build I could try I can give you an answer pretty quick.   (I technically can build a firefox install with the patch applied but I've not done it for a bit so it will probably take me several days to work through all the steps again)
alavaliant: thanks for volunteering! Sorry I didn't notice your comment until now.

I've pushed a patch to try that works for me in the non-proxy case:
https://tbpl.mozilla.org/?tree=Try&rev=fe6337b1609c

The build is available here:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/gsharp@mozilla.com-fe6337b1609c/try-linux64/

Let me know if you can reproduce the problem you reproduced earlier in that build.
Flags: needinfo?(alavaliant)
Created attachment 731257 [details] [diff] [review]
patch

This patch blocks authentication prompts from appearing by adding an nsIAuthPromptProvider implementation to the search suggest channel's notificationCallbacks. This nsIAuthPromptProvider returns a no-op nsIAuthPrompt2 implementation.

The idea is to effectively make nsHttpChannelAuthProvider::PromptForIdentity a no-op. I can't just return null for nsIAuthPrompt2, because then it would fall back to the load group's callbacks which eventually finds the implementation in nsDocShell, I believe.

It would be nice if there was a simpler way to do this, with a flag on the channel or something.
Attachment #724651 - Attachment is obsolete: true

Comment 26

4 years ago
Comment on attachment 731257 [details] [diff] [review]
patch

+    this._request.channel.notificationCallbacks = new AuthPromptOverride();

I'm not sure, but wouldn't this potentially suppress SSL warnings, too?

+    return {
+      promptAuth: function () {},
+      asyncPromptAuth: function () {}
+    };

This is supposed to be an nsIAuthPrompt2, so doesn't this need a QI function at least? I assume you tested it and it works as-is, but I thought that it was supposed to implement QI.
Attachment #731257 - Flags: feedback-
(In reply to Ben Bucksch (:BenB) from comment #26)
> I'm not sure, but wouldn't this potentially suppress SSL warnings, too?

No, we don't have SSL-related prompts anymore (bug 799009).

> This is supposed to be an nsIAuthPrompt2, so doesn't this need a QI function
> at least?

No, XPConnect handles plain old JS objects just fine.

Comment 28

4 years ago
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #24)
> alavaliant: thanks for volunteering! Sorry I didn't notice your comment
> until now.
> 
> I've pushed a patch to try that works for me in the non-proxy case:
> https://tbpl.mozilla.org/?tree=Try&rev=fe6337b1609c
> 
> The build is available here:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/gsharp@mozilla.
> com-fe6337b1609c/try-linux64/
> 
> Let me know if you can reproduce the problem you reproduced earlier in that
> build.

Thanks for that (I'd been having very limited luck trying to make my own build,   for some reason from multiple computers/different isps my cloning of the source repo was timing out or erroring our part way through the checkout and I hadn't found any tarballs of the source modern enough to apply the patch to so).

I've tested and was unable to reproduce the problem using your supplied build;     when freshly started up typing in the search dialog box didn't bring up any proxy auth boxes,   the first one I got was when actually submitting the search result (to load the search page),  then no further prompts to login to the proxy server showed up when using the search box further  (but search suggestions started working for further searches  after the proxy login was done via the first webpage load).     So if I'm understanding the intention of the patch it appears to be working perfectly.
Flags: needinfo?(alavaliant)
Gavin, I think you are on a good way here.  However, your implementation of nsIAuthPrompt2 has to be finished.  E.g. asyncPromptAuth has to call the callback with onAuthCancelled immediately, otherwise the channel hangs believing there is an auth prompt user has to accept or cancel.  onAuthCancelled is called when the dialog is canceled to continue the code path.
Thanks, a lot for the testing, alavaliant!

I'll submit an updated patch that addresses Honza's feedback.
OS: Windows 2000 → All
Hardware: x86 → All
Created attachment 732386 [details] [diff] [review]
patch
Assignee: nobody → gavin.sharp
Attachment #731257 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #732386 - Flags: review?(honzab.moz)
Comment on attachment 732386 [details] [diff] [review]
patch

Review of attachment 732386 [details] [diff] [review]:
-----------------------------------------------------------------

r=honzab

::: toolkit/components/search/nsSearchSuggestions.js
@@ +536,5 @@
> +      },
> +      asyncPromptAuth: function () {
> +        throw Cr.NS_ERROR_NOT_IMPLEMENTED;
> +      }
> +    };

If this works w/o QI then we are OK.
Attachment #732386 - Flags: review?(honzab.moz) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/aaae69fde562
Target Milestone: --- → Firefox 23
This got backed out, here's a try push:
https://tbpl.mozilla.org/?tree=Try&rev=4369c931e9c6
Re-landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/448765c6360b
https://hg.mozilla.org/mozilla-central/rev/448765c6360b
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Blocks: 816021
You need to log in before you can comment on or make changes to this bug.