Closed Bug 80652 Opened 23 years ago Closed 9 years ago

FTP needs password authentication cache

Categories

(Core Graveyard :: Networking: FTP, enhancement, P2)

Product:
Core Graveyard
Component:
Networking: FTP
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: benc, Unassigned)

References

Details

(Keywords: helpwanted, topembed-) 

STEPS:

1- Connect to any system that requires a username and password to ftp.

When you are browsing, you only are chanllenged for a password once.

(While working on another bug, I was using:
ftp://<user>@frame.packetgram.com/export/home/docs/pktg/mozilla/bugzilla/70375/)

2- When you actually try to get a file from that window, EVERY file transfer,
even the same file twice, results in an auth challenge.
-->ftp
Assignee: neeti → dougt
Component: Networking → Networking: FTP
adding myself to Cc.  Seeing this on the may 17 builds.  Is this going to get
fixed for the .91 beta?  If not it should be release noted indefinitely.
mass setting milestone.  if this is something you believe is more urgent then 
the milestone that I just sent, please send me mail.
Target Milestone: --- → mozilla0.9.3
Priority: -- → P2
Currently every control connection which gets establish will ask for a
username/password.  Changing this would require some notion of page lifespan so
that the auth cache can be cleared on a page trasistion (disconnect).  

The potential problem that I see is this.  Imagine that you are connected to
ftp://foo with your username and password.  For whatever reason, you want to log
in as anonymous or a different user.  How would you flush that auth cache to do
this?  I would guess that when you leave the page, a notification would come
back in notifing the protocol handler so that it can flush the auth cache.  

Moving milestone out.
Target Milestone: mozilla0.9.3 → mozilla1.0
That's a problem with all auth.

The workaround is to use a URL w/ the username+password in it.
OS: other → All
Hardware: PC → All
Target Milestone: mozilla1.0 → mozilla0.9.4
I haven't looked at how directory behaved, maybe this is html only.

Since this is HTML view, the HTML links have a specific state
(ftp://<username>@hostname/path), that has no password.

This may just be the way it should work. If we aren't investing in HTML, if we
are going back to make the directory style view work, then this might not be
worth fixing.
re-bucket-ing milestone
Target Milestone: mozilla0.9.4 → mozilla0.9.5
reassigning to bbaetz@cs.mcgill.ca.
Assignee: dougt → bbaetz
-> 1.0.

ftp needs an auth cache like http uses. The interesting question is why is
another control connection being created?
Target Milestone: mozilla0.9.5 → mozilla1.0
QA Contact: tever → benc
changed summary to enhancement - this behavior does not really block any usage 
b/c there is a workaround (HTTP is the opposite b/c http: URLS don't support 
user:password syntax, so you cannot clear your auth w/o restarting).
Severity: normal → enhancement
Summary: ftp: auth not persistent w/ file transfers → [RFE] FTP - auth cache
RELNOTE:
FTP does not cache your passwords. If you use passwords, you will need to 
authenticate for every file transfer.
Keywords: relnote
cc jatin for release note comments above.
Keywords: 4xp
benc: HTTP urls can contain username:password.
Was it added after RFC 1738?
benc: The RFC is not always right, especially the uri related onces :) But yes,
probably.
->future, +helpwanted
Keywords: helpwanted
Target Milestone: mozilla1.0 → Future
*** Bug 135842 has been marked as a duplicate of this bug. ***
*** Bug 132124 has been marked as a duplicate of this bug. ***
*** Bug 135842 has been marked as a duplicate of this bug. ***
+nsbeta - This make life in non-anonymous servers really miserable.
Keywords: nsbeta1
*** Bug 149112 has been marked as a duplicate of this bug. ***
I have no time to work on mozilla at the moment, so dougt is taking over FTP

open ftp bugs -> him
Assignee: bbaetz → dougt
Summary: [RFE] FTP - auth cache → FTP - auth cache
*** Bug 200947 has been marked as a duplicate of this bug. ***
Summary: FTP - auth cache → FTP needs password authentication cache
This bug appears in BuildID: 2003040304

Rather annoying..

I spent a lot of time yesterday trying to get servers to work well with
Composer's Publish feature. Unlike Netscape Enterprise Server, it seems that
getting HTTP PUT working on Apache is non-trivial. Another reason this is more
likely is that more users probably work in file spaces that do NOT have
anonymous access than I originally thought. I had forgotten how time consuming
configuring anonymous correctly can be, and on my new server, I have user-access
only.

This means that many people in my situation would use the path of least
resistance, and use FTP to publish files to subtree that has access control. In
this environment, you have to embed your username into the ftp URL, or you get
an anonymous failure, which does not throw a auth prompt (bug 124561). 

So, in this situation, you keep getting asked for a password again and again. If
you use password manager, then the dialogs do not appear, but you have been
forced into putting your auth state into the profile. That is probably
over-kill, I think most people would want to be able to authenticate once, just
for the entire session, no more, no less.
Keywords: topembed
topembed-, not blocking embeddors right now
Keywords: topembed → topembed-
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
*** Bug 288318 has been marked as a duplicate of this bug. ***
> So, in this situation, you keep getting asked for a password again 
> and again. If you use password manager, then the dialogs do not 
> appear, but you have been forced into putting your auth state into 
> the profile. 

Why can't the FTP password just be managed like a HTTP Basic 
Authentication password (in the browser instance)? 
It could be, but FTP doesn't have a convenient way to access the HTTP
authentication cache.  Indeed, it probably makes sense to factor the HTTP
authentication cache out into a generic authentication cache for use by any
networking protocol.  It should not be that hard to do that.  It just takes some
time.  Are you volunteering?  ;-)
*** Bug 288318 has been marked as a duplicate of this bug. ***
mass reassigning to nobody.
Assignee: dougt → nobody
Keywords: relnote
enhancements to ftp belong to addons these days
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.