User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040512 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040512 A confirm dialog repeatedly pops-up even after selecting 'OK', warning that "You are about to logon to the site "www.somesite.com" with the username "ken" but the site does not require authentication. This may be an attempt to trick you." Reproducible: Always Steps to Reproduce: 1. Load to a URL that does not requires www-authenicate. 2. Warning pops-up, confirm (OK). 3. Click another link - re-occurs. Expected Results: Either remember that OK was selected, or do not present this dialog if the connection was established from a bookmark (only when users clicks on a link from a site). Many servers dont send authenticate headers after an initial login, since they maintain login state by session cookie/URL - so will never subsequently send a www-auth challenge (while user logged in). Moreover, some users like to bookmark VERY frequently used sites with the crendentials - but some paths on the sites do not immediately require authentication - then the pupose of storing the crendentials is to preemtively make them available if a restricted URL is later entered. For this reason, one possible idea of 'clearing' the URLs credentials if not auth is required, would not work.
I actually just verified that this new behavior may not even be neccesary.. watching the header exchange, even when I choose 'OK' on the dialog, no authenticate data is sent ot the server anyway, enless and until after the server first sends a 401-auth response. So at least the dialog stating "even though the server doesnt require auth" is accurate - but the part about "about to login" is not. This header behavior has already been the expected behavior - browsers should only send an "Authorization:" response when challenged, and Mozilla has always done that to my knowledge. Perhaps this alert should only apear when clicking on a foreign site's link AND the target site also issues a challenge, which is the only time (that I know) Mozilla would send any kind of Login information anyway. The feature has definate security value though, glad to see people are making this software more and more safe. Mozilla rocks.
The idea here is to tell you (as a user who knows nothing about usernames in URLs) that a url like http://email@example.com/ is not what it looks like...
Yes, we expected that this might annoy some users, and you bring up an interesting scenario in which this prompting is particularly annoying. You may appreciate knowing that you can effectively disable this "feature" by adjusting this hidden user preference: network.http.phishy-userpass-length Just load about:config, right click and choose New->Integer. Enter this pref name and set the numeric value to some large number.
Thats a great point!!! I've seen lots of that junk mail mental midget stuff going around... So perhps the dialog can be supressed enless click on a link thats not trusted, and then also after the first click into the site. This would solve the recurrence of the alert when: -User already acknowledged the alert and desires to continue clicking through links on the site with same credentials (since subsequent relative (host-less) links inherit the URL-bars crendentials, thus invoking the alert) -User uses bookmarks with user:pass syntax to premptively provide crendentials.
Thank you Darin, I forgot to mention that I didnt see the preference for disabling it - but disabling altogether would diminish its clear value - so perhaps the preference setting *should not* be included - theres too many users who dont understand the bad potential of disabling it. I'd propose to show the dialog always, except when outside the sandbox (bookmarks). The feaure has real merit.
PS by "perhaps the preference setting *should not* be included", I meant not included in the Edit-Prefences dialog, where layman users (or even nieve sysadmins in corp environments) could disable it. The about:config method is fine IMO.
Right, we have no intentions of surfacing this preference in the UI! I agree that we could remember the fact that the user acknowledged this dialog per domain per session. That would not be hard to implement. We already store authentication data per domain per session, so this is just an additional 'bit' to remember. -> me dveditz, asa, bz: what do you guys think? do you agree with this approach? also, it may be more difficult to sandbox bookmarks. i agree that that is worth doing, but it may be more complicated to implement.
I sure hope a patch for this can get in before the release version - I spent part of my day trying to get the "network.http.phishy-userpass-length" setting to stay persistent - it wouldnt get dropped into my prefs.js file for some reason when added from about:config, so after a restart the pop-up kept nagging me - even after manually adding to prefs.js, same thing. Finally discovered that (apparently) the param has to be put into user.js. user_pref("network.http.phishy-userpass-length", 1024); If this goes unpatched into the 1.7 release, its almost certain to be the biggest single complaint, sorry to say. It drove me nuts.
*** Bug 260989 has been marked as a duplicate of this bug. ***
dupe of bug 248945 ? I know this one is older, but the other one has already votes.
On re-reading the two this bug appears to be wanting to suppress the "suspicious auth" dialog (site doesn't actually require auth, yet), whereas bug 248945 covers the "defensive auth" check.
HUH ? i dont see this as an enhancement if i visit a site, aknowledge i want to use it with login info. WHY is it an enhancement when mozilla keeps asking me wether it should login tho i navigate on the same site ???
Perhaps Moz needs to remember the decision for each auth:url, on a per session basis. It was also mentioned that a preference to disable this 'feature' might be added but I havent noticed it, at least in FF (made the move 3 months ago :-).
bug 248945 covers the case of sites that really require auth. The dialog in this bug is the "Suspicious Auth" dialog that comes up when the URL contains auth but the site doesn't request it. This is a sure-fire sign of phishing (fake auth like http://www.yourbank.com:firstname.lastname@example.org) which is why we warn. Refining this behavior (remembering that site was warned in this session already, or a permanent per-site suppression) is the very definition of an enhancement. This is not a value judgement that it's not important, I personally strongly object to the enhancement/bug distinction being lumped in with the bug severity field since that implies enhancements are never serious. I'm basing this on Ken's initial comment 0. If this really is about the "defensive" auth then it's a straight-up dupe of bug 248945. Since Darin owns both and we've asked about dupes before (comment 10, bug 248945 comment 5) he must think this is the other dialog too.
*** Bug 248945 has been marked as a duplicate of this bug. ***
I duped the other bug to this one. It's the same can of worms really. I may not have time to implement a fix for this bug in time for Firefox 1.1 (and other Gecko 1.8 based products), so help would definitely be appreciated.
*** Bug 227414 has been marked as a duplicate of this bug. ***
*** Bug 278876 has been marked as a duplicate of this bug. ***
*** Bug 276018 has been marked as a duplicate of this bug. ***
*** Bug 291734 has been marked as a duplicate of this bug. ***
*** Bug 302822 has been marked as a duplicate of this bug. ***
I think this feature should have an option to be disabled on a PER-SITE basis, via a (hidden) pref. Just as it is done with NTLM auth.
I agree with Johan, it would be specially useful to whitelist intranet addresses.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258