Closed Bug 406787 Opened 17 years ago Closed 17 years ago

Empty index shown after ftp error if you hit return in the URL Bar

Categories

(Core Graveyard :: Networking: FTP, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9.1b1

People

(Reporter: IDontUseMozillaAnyMore, Assigned: michal)

References

Details

(Keywords: verified1.9.0.6)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 If you go to a secure website and happen to get your username or password wrong Firebox still caches those credentials for future loads of that page. Until recently the only way to clear that cache was to quit Firefox and restart it. Even now you have to select Tools/Clear private data then clear a load of check boxes and press enter. Pretty cruel punishment for simply getting your password wrong. Firefox should not be caching the username and password if you fail to login correctly. Reloading the page should ask again for the username and password. Reproducible: Always Steps to Reproduce: 1. Go to a secure website. 2. Enter your username and get the password wrong. An error 401 is generated by the server. 3. Attempt to reload the page to have another go at entering your password. Actual Results: The same error 401 is returned. Expected Results: The username and password should be requested again.
Component: Security → Networking: HTTP
Product: Firefox → Core
QA Contact: firefox → networking.http
Happens on error 530 too. Firefox 3, all versions.
Component: Networking: HTTP → Password Manager
Product: Core → Firefox
QA Contact: networking.http → password.manager
Component: Password Manager → Networking: HTTP
Product: Firefox → Core
QA Contact: password.manager → networking.http
This is wfm with Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:1.9b3pre) Gecko/2007122503 SeaMonkey/2.0a1pre and FF3.0b1 using http://matti.no-ip.org/admin and entering wrong login.
(In reply to comment #2) > This is wfm with Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:1.9b3pre) > Gecko/2007122503 SeaMonkey/2.0a1pre and FF3.0b1 using > http://matti.no-ip.org/admin and entering wrong login. > Agreed it does seem to work in 3.0 beta 2, but not in any version 2 or previous
(In reply to comment #2) > This is wfm with Mozilla/5.0 (Windows; U; Windows NT 6.0; rv:1.9b3pre) > Gecko/2007122503 SeaMonkey/2.0a1pre and FF3.0b1 using > http://matti.no-ip.org/admin and entering wrong login. > I cannot get it to work. Did you try on a ftp connection? (you can try on ftp://adys.stools.net/)
Please don't add the reply because it makes bug reports longer and worse readable. For the first thing, ftp and http are absolut different things. I found only one very minor problem with ftp that I get an empty index if I hit return in the URL bar (for reloading) but i get a new prompt if I hit reload or shift+reload. This could be caused by teh fast forward/backward cache. Do you mean that minor problem ?
It also happens if you try to enter the URL again (or just press enter). Using reload indeed prompts me again.
I can reproduce this with FTP and the ftp URl from comment #4 1) Open Tab with the FTP URL 2) hit cancel 3) put the cursor in the URL Bar and hit enter 4) you get an empty index
Severity: normal → minor
Status: UNCONFIRMED → NEW
Component: Networking: HTTP → Networking: FTP
Ever confirmed: true
QA Contact: networking.http → networking.ftp
Summary: Firefox should not cache username and password when an error 401 being returned by server. → Empty index shown after ftp error if you hit return in the URL Bar
This bug is similar to #122548. nsICacheSession::OpenCacheEntry() creates new empty cache entry if it doesn't exists. When whatever fails during FTP communication the valid empty entry stays in the cache. This patch changes the behaviour so that cache entry is deleted by default when it is released. It is not deleted if - valid directory listing was obtained - cache was used to read the data Patch from bug #122548 is no longer necessary but I kept it because it make sense to doom and release cache entry before it is filled by the file content.
Assignee: nobody → michal
Status: NEW → ASSIGNED
Attachment #326454 - Flags: review?(doug.turner)
Comment on attachment 326454 [details] [diff] [review] destroy cache entry if it doesn't contain valid directory listing [Checkin: Comment 12] r+sr=bzbarsky. Silly mutating bugs!
Attachment #326454 - Flags: superreview+
Attachment #326454 - Flags: review?(doug.turner)
Attachment #326454 - Flags: review+
Keywords: checkin-needed
Comment on attachment 326454 [details] [diff] [review] destroy cache entry if it doesn't contain valid directory listing [Checkin: Comment 12] http://hg.mozilla.org/mozilla-central/rev/e53451896ad3
Attachment #326454 - Attachment description: destroy cache entry if it doesn't contain valid directory listing → destroy cache entry if it doesn't contain valid directory listing [Checkin: Comment 12]
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
Version: unspecified → Trunk
Attachment #326454 - Flags: approval1.9.0.5?
Comment on attachment 326454 [details] [diff] [review] destroy cache entry if it doesn't contain valid directory listing [Checkin: Comment 12] Too late for 1.9.0.5 but we can look at for next time.
Attachment #326454 - Flags: approval1.9.0.5? → approval1.9.0.6?
Comment on attachment 326454 [details] [diff] [review] destroy cache entry if it doesn't contain valid directory listing [Checkin: Comment 12] Approved for 1.9.0.6, a=dveditz for release-drivers.
Attachment #326454 - Flags: approval1.9.0.6? → approval1.9.0.6+
Keywords: checkin-needed
Whiteboard: [c-n: cvs/1.9.0]
Checked into 1.9.0 branch
Whiteboard: [c-n: cvs/1.9.0]
Verified fixed for 1.9.0.6 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6pre) Gecko/2009011304 GranParadiso/3.0.6pre.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: