Closed Bug 133755 Opened 23 years ago Closed 5 years ago

username/password dialog when having favicons from password protected sites in bookmarks

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

on one of my .htaccess protected sites I have a favicon.ico. The favicon.ico is inside the .htaccess protected area. I've added this site to the bookmark. Now when ever I open the bookmark folder I'm prompted for a username/password! Very very bad!
favicon qa --> claudius@netscape.com
QA Contact: paw → claudius
Blocks: 120352
Can you give a URL where we can test this?
http://www.mozillazine.org/forums/viewtopic.php?t=3162 describes this better: (quote) In one example, I go to thedomain/subdirectory (which is not protected) and access it fine. however, phoenix automatically seeks out thedomain/favicon.ico and prompts me for my username/password after getting the 401 forbidden response. (/quote)
Log into the following URL: http://gemal.dk/browserspy/password-works.html with: username: test password test now add the page to the bookmarks and restart your browser and when you enter your bookmarks you will be asked for a password. As least this is true for Phoenix since it uses icons in it's bookmarks!
URL: http://gemal.dk/browserspy/password-w...
this is very annoying if you add such .htaccess protected favicon site to the personal toolbar folder: everythime starting the browser the authentication window pops-up..... maybe it is better to cache the favicon and just check if there is a new one everytime the user access the page?
*** Bug 225095 has been marked as a duplicate of this bug. ***
I made the duplicate, so this is another confirmation of the bug. My search query seemed reasonable at the time (icon auth bookmark), but didn't turn up this bug.
*** Bug 228876 has been marked as a duplicate of this bug. ***
*** Bug 229459 has been marked as a duplicate of this bug. ***
*** Bug 233216 has been marked as a duplicate of this bug. ***
I also have this problem. I bookmarked the CPanel link to my webpage. I notice that it doesn't ask me for username/pass everytime though. It only does it if: - I open firefox - I go to my CPanel, and log correctly - Close firefox - reopen firefox - Click on Bookmarks - Bang! asking user/pass If I don't go to my CPanel at all during a session, nothing will be asked (And my CPanel icon will not be there in the bookmarks (blank sheet icon))
Oops, I should test better before writing a comment. My previous comment is exact BUT, the user/pass dialog will be asked as long as I have logged in the previous session. Thus, if, in session 1, I go to my cpanel, clicking on Bookmarks in session 2 will pop-up the user/pass dialog. If I click OK in this dialog, even if I don't go to my cpanel, this dialog will popup again in session 3. However, if I click on cancel in session 3, session 4 will not ask for a user/pass.
I am seeing the same behaviour in the same scenario as Virgil (logging into my CPanel account). Here is exactly what I'm seeing: Session 1: Visit CPanel site and log in. The icon in the bookmarks menu is now the CPanel logo. Session 2: Go to the bookmark folder with the CPanel bookmark. An authentication dialog will pop up. If I cancel it, the bookmark's icon will now be blank. Session 3: Go to the bookmark folder with the CPanel bookmark. The bookmark will now have the generic bookmark icon. No authentication dialog will appear. So it appears the authentication dialog only appears if you logged into the site in question in the previous session. Otherwise, it assigns the bookmark the generic icon and does not try to access the password protected site.
*** Bug 238792 has been marked as a duplicate of this bug. ***
Why is this Status: NEW? Why is this Component: XP Apps rather than Bookmarks? This is a common problem for anyone that uses a corporate intranet (assuming it has a favicon.) I have a bookmark in my Bookmarks toolbar that is on the corporate intranet. Every time I open Firefox - even by clicking on a link to www.yahoo.com - I need to authenticate against the intranet so the favicon can appear. If I open Firefox to go to the corporate intranet, the situation is worse - I have to authenticate twice! Once for the favicon, and once for the page.
Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.
Assignee: firefox → guifeatures
I just stumbled across this bug myself recently as well, through the exact same case mentioned in comment #11. Very irritating-- and there seems to be no rhyme or reason to when I'm actually asked for my site's userid/password...
*** Bug 240764 has been marked as a duplicate of this bug. ***
Depends on: 240792
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040418 Changing Hardware/OS to All. pi
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 241558 has been marked as a duplicate of this bug. ***
What about when you have a public sub-directory on a site, but the top directory is private? The browser tries to get the file, all the while causing auth dialogs to appear for no reason. Same behavior, but it has absolutely nothing to do with bookmarks. Ideally though, the browser should just supress all favicon-related errors.
It does? Can you reproduce that? Hopefully the web author would place a copy of the shortcut icon in the publicly-accessible directory and use a <link rel="shortcut icon" href="/public/fav.ico"> to point to the publicly accessible favicon. If there was a <link rel="shortcut icon" href="/fav.ico"> on the publicly-accessible directory I would expect the browser to ask me for credentials. This would be a feature. If there was no <link> at all I would not expect the browser to ask me for credentials. That would be a bug.
*** Bug 242229 has been marked as a duplicate of this bug. ***
Can someone change the Component to Bookmarks?
Assignee: guifeatures → p_ch
Component: XP Apps: GUI Features → Bookmarks
QA Contact: claudius → seamonkey.bookmarks
*** Bug 242329 has been marked as a duplicate of this bug. ***
*** Bug 242618 has been marked as a duplicate of this bug. ***
*** Bug 243451 has been marked as a duplicate of this bug. ***
I searched, I promise -- thanks for marking that ^ a dupe for me. Looks like my entry doesn't add any new info, but it does list the steps to get the bug.
*** Bug 244170 has been marked as a duplicate of this bug. ***
*** Bug 247304 has been marked as a duplicate of this bug. ***
*** Bug 249059 has been marked as a duplicate of this bug. ***
*** Bug 249762 has been marked as a duplicate of this bug. ***
There have been a couple of favicon related bugs fixed in the past few days. Unfortunately, it seems like some of those fixes have made this bug even more annoying. Before, when Firefox popped up the password dialog and I cancelled it, Firefox would "forget" about the icon until I visited that page again. This way, I could go a few sessions without seeing the problem (at least until I had to visit that site). Now, I get the authentication popup ever single session when I first go to the bookmark folder with that link.
Flags: blocking-aviary1.0?
Is this a firefox bug or a mozilla suite bug? (The Product here is set to Browser, so if it's a firefox bug, this should get changed to Firefox.) For firefox, the patch in bug 252006 should fix this issue.
It's a Mozilla suite bug, but it did also happen in Firefox. As the code is forked, Firefox should have a separate bug, but if the patch you mention fixes it, then there's no need. My apologies for confusing the situation...
Flags: blocking-aviary1.0?
I am using today's (2004/07/19) build of Firefox which should include your fix for bug 252006 but I still see the issue this bug is about. I'll open a Firefox bug if one doesn't already exist.
(In reply to comment #36) > I am using today's (2004/07/19) build of Firefox which should include your fix > for bug 252006 but I still see the issue this bug is about. I'll open a Firefox > bug if one doesn't already exist. I can't reproduce it.. please do open a new bug in Firefox/Bookmarks, with some information on how to reproduce it. Testing with the test URL on this page works for me (I get prompted when I first visit the bookmark, which is correct, and the favicon updates; on subsequent browser restarts I see the favicon with no prompt).
Looks like bug 120304 is what's causing the problem for me. I see these when the favicon is located in a protected area AND is accessed via HTTPS. The favicon isn't cached on HTTPS sites, so when I view the bookmark folder with that bookmark, it tries to grab the bookmark icon and gets the authentication dialog.
*** Bug 256724 has been marked as a duplicate of this bug. ***
*** Bug 261313 has been marked as a duplicate of this bug. ***
Got a similar situation here. http://example.com/ is password protected http://example.com/users/ isn't, we use the apache directive "Allow from all", on every page load firefox and seamonkey show a HTTP authentication dialog trying to get the favicon. In the end I added <Files favicon.ico>Allow from all</Files> to resolve this but would prefer if something could be done at the application level? Couldn't the HTTP response code be checked and if its not 200/304 then go on the assumption that no icon exists.
Product: Browser → Seamonkey
Note: some of the dupes here (bug 242229 & bug 261313) are about inline protected icons, not bookmarks. Either they need to be redirected to a separate bug, or the eventual patch should handle code-401 icons in general, not just a bookmark-specific dodge.
Reassigning as per Bug #32644
Assignee: p_ch → nobody
nsIFaviconService is part of Places I think. Moving.
Component: Bookmarks & History → Places
Product: SeaMonkey → Toolkit
bug still exists, tries to refresh favicon on every tab and bookmark at startup? at least make it happy to use the cached favicon.
bookmarks only use locally cached icons, if this still happens it's something else in browser.
Component: Places → General
Product: Toolkit → Firefox

Mossop, do you know if this is still an issue e.g. after bug 1453751?

Depends on: 1453751
Flags: needinfo?(dtownsend)

(In reply to Dão Gottwald [::dao] from comment #47)

Mossop, do you know if this is still an issue e.g. after bug 1453751?

As Marco says all favicons are cached locally for use in bookmarks etc. so there shouldn't be any way for the bookmark menus to trigger an auth dialog at this point.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(dtownsend)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.