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)
Core Graveyard
Networking: FTP
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.9.1b1
People
(Reporter: IDontUseMozillaAnyMore, Assigned: michal)
References
Details
(Keywords: verified1.9.0.6)
Attachments
(1 file)
4.48 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
dveditz
:
approval1.9.0.6+
|
Details | Diff | Splinter Review |
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.
Updated•17 years ago
|
Component: Security → Networking: HTTP
Product: Firefox → Core
QA Contact: firefox → networking.http
![]() |
||
Updated•17 years ago
|
Component: Networking: HTTP → Password Manager
Product: Core → Firefox
QA Contact: networking.http → password.manager
Updated•17 years ago
|
Component: Password Manager → Networking: HTTP
Product: Firefox → Core
QA Contact: password.manager → networking.http
Comment 2•17 years ago
|
||
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.
![]() |
Reporter | |
Comment 3•17 years ago
|
||
(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/)
Comment 5•17 years ago
|
||
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.
Comment 7•17 years ago
|
||
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
Updated•17 years ago
|
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
Assignee | ||
Comment 10•17 years ago
|
||
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.
![]() |
||
Comment 11•17 years ago
|
||
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+
Assignee | ||
Updated•17 years ago
|
Keywords: checkin-needed
Comment 12•17 years ago
|
||
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]
Updated•17 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
Version: unspecified → Trunk
Assignee | ||
Updated•16 years ago
|
Attachment #326454 -
Flags: approval1.9.0.5?
Comment 14•16 years ago
|
||
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 15•16 years ago
|
||
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+
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Updated•16 years ago
|
Whiteboard: [c-n: cvs/1.9.0]
Comment 16•16 years ago
|
||
Checked into 1.9.0 branch
Keywords: checkin-needed → fixed1.9.0.6
Whiteboard: [c-n: cvs/1.9.0]
Comment 17•16 years ago
|
||
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.
Keywords: fixed1.9.0.6 → verified1.9.0.6
Updated•1 year ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•