This is probably going to fork to several bugs, but the general problem is that our handling of ftp URLs is heavily focused on anonymous ftp. Nothing wrong with that, but we might want to think of some cases (like out of the location bar or clicking on a link), where a failure to get anonymous FTP working should return a username + password dialog, rather than an error.

-> ftp Do you have a case where we don't do that? If we're denied anon access, then we pop up a dialog box.

I think it says "anonymous access denied", rather than popping up auth. If you have a user name (ftp://user@somthing.com) it will prompt for just the password. Actually with 0.9.8, it doesn't seem to pop up anything (?).

Ah, right. This is the same problem as bug 114118, although I'm not sure of the solution. The problem is that "anonymous login denied" is the same as "too many users" or "I don't feel like talking to you today". I'm not really sure what the solution is.

The actions it takes may be dependent on the response it gets from the FTP server.. it is not consistent: ftp://ftp.swva.net It does nothing at all! ftp://kontek.net It says "Login or Password incorrect." and gives no way to enter them.

The actual message displayed comes from the server, and I don't really want to try to parse it to see what the server is telling us ftp://ftp.swva.net is a different bug, related to double-PASV

I think there are two basic levels of ftp support: 1- anonymous browser, which is working pretty good now. 2- power-user/intranet client, which is an extra level of sophistication. For the second level, things like showing the error message text and offering interactive login dialogs, and many of the ftp client features, they all fit into this areal.

*** Bug 115058 has been marked as a duplicate of this bug. ***

Note that this behaviour (anon access doesn't pop up a dialog) is the same as ns4. I don't have a busy server to test ie on, but ie pops up a dialog if anon access is denied, which also has a checkbox to use anon access. If you choose that then you can enter a different email, and the setting is saved.

Yeah, but there is no way of providing a different username unless you hack the URL. If someone wants to defend the lameness of NS 4 in this area, go ahead. I have always found it really annoying.

This is critical to Composer Publishing feature. We find that if both the username and password is missing, or either of them are incorrect, we get the "Login incorrect" error message rather than calling nsIWebProgressListener::promptUsernamePassword. If username is correct and password is missing, nsIWebProgressListener::promptPassword is called correctly.

That isn't this bug - its more bug 114118. This is a limitation in the ftp spec. Although the server can tell us that it doesn't support anon users when it gets given the username, I haven't found one which does, and so the code to call PromptUsernameAndPasword is untested by me. How about always requiring a username? Very few people are likely to wnat to (or be able to) publish html pages made with composer to an ftp server which requires anonymous login Also, that dialog comes from the server. Should I add "An error occurred. The server responded:\n" to the top of it? If you think so, then please open a new bug on me for that.

Bug 119870 is for tidying the message up. You should get an appropraite error message though, and I did get one when I tested this.

per adt, not critical for nsbeta1. hence minus.

Sorry, Gagan, but this bug is very critical for Composer. Sorry to not make the dependency more explicit earlier. The main issue is discussed in bug 124561: When username/password is missing, FTP assumes anonymous and therefore fails instead of prompting for the username and password via nsIAuth::promptUserName notification.

Bug 124561 is this bug, but ISTR seeing the bug you're talking about - do you have the number on hand? Composer can handle the username=="" case internally, I guess, since anonymous publishing is likely to be the uncommon case. I am very unlikely to get to this in the near future. The dialog would need to have a checkbox for 'try again anonymously' (see iw). Can I do this with the proptservice? I can't use xul from within necko.

Bradley: Composer publishing would NOT want a checkbox to use anonymous login. So all we want it to call the usual nsIAuth::promptUserNamePassord callback for nsIWebBrowserPersist. Do we need to pass in some flag to nsIWebBrowserPersist that could propagate to FTP code just for this 'mode'? We must have this fixed for publishing to work correctly.

We have noticed that 4.x has exactly the same behavior. If I can figure out how to detect exactly what status messages tell us we have a "bad login", I may be able to trap this prompt error and put up the appropriate username/password dialog from Composer, and then restart the publish request. Any help on what status messages and values to observe would be appreciated.

So you want ftp to prompt always, even if there is no username, instead of defaulting to anonymous?

The ftp "bad login" errro code is the same as the "too many users" code. This is an ftp protocol limitation, and I can't do anything about it.

I know this might poke a hole in the URL format of ftp://, but I've always wanted is some kind of ftp URL that says "ask for a username"! I can't believe how many times I sent someone a URL that said: ftp://<user>@server/dir/file. It's annoying because then they have to copy the URL and hack out the username. Maybe we need treat: ftp://:@server/dir/file ftp://@server/dir/file as a way of forcing a user|pass prompt.

Actually, this won't do what you want for composer. Consider the very common case of a server which allows anonymnous logins and user logins for uploads. The anon login will succeed, but the upload will fail because of a permisions error. Should we really then offer to log in as someone else? The "incorrect permissions" error is teh same code as the "no such directory error", so I can't count on that. I suspect that this is why ns4 behaves the same. I don't see why composer can't just require a non-empty username - its an error 99% of the time, since publishing a webpage qhich allowed an anon login would be a massive security hole on the server side.

Yes, 4.x behaves exactly like this. So FTP behaves differently than HTTP. That's no problem; we can assume different rules and validation behavior based on scheme. I can adjust for these differences on the Composer side to enforce username while in the Publish dialog, and put up our own username/password dialog before publishing remote files without the Publish dialog. Benjamin: Unfortunately, this won't address non-Composer FTP cases that you site.

Perhaps this bug isn't in line with what I want to report. Here goes anyway: Moz (0.9.9 - build 2002031104 btw) doesn't grok the ftp://[user[:pass]@]hostname/ conventions for dealing with authentication. Instead it throws up a "Command not understood" alert, while IE - and the squid proxy that its going through - deal with it just fine. Perhaps I'm misreading something, but some other comments made for this bug suggest that Moz could at some time deal with ftp://[user[:pass]@]hostname/, in which case I have to wonder it was removed. pout. :( Incidentally, I agree with the suggestion that Moz recognize the 331/530 error code and prompt for new authentication. That the "bad login" and "too many users" error codes are identical doesn't preclude Moz from prompting: ,--------------------------------------------------, |[ ] FTP connect failed | |--------------------------------------------------| | Failed to login to the ftp server foo.bar.com | | The server said: "530: too many users" | | | | ( ) Anonymous login: | | Username: [auser@some.account.com ] | | (*) Authenticated login: | | Username: [joe ] | | Password: [******** ] | | | | ,===============, ,---------------, | | | Try again | | Cancel | | | `===============' `---------------' | '--------------------------------------------------' In the event that there are x-plat issues with a dialog, I suppose that this could just as well be a builtin: form like the NCSA browser used to have.

ftp://user:ps@host does work for me, although I haven't tried with a squid proxy recently. Yes, that dialog is this bug.

cmanske: I'm not going to get to this for 1.0. IIRC, we agreed on IRC that you would handle this in the composer backend. If not, and you want this for 1.0, then you'll need to find someone else to do this. (see my comment #21 for why this probably wouldn't help you, anyway) ->1.1beta

*** Bug 134369 has been marked as a duplicate of this bug. ***

gagan: I'm not going to be able to find time to get to this, if you want it for your release, you'll have to find someone to deal with it. Sorry...

->morse

changed summary in attempt to reduce # of new dupes. if anyone can improve this, please do so.

_Any_ failure to authenticate should throw up a prompt. After all, an anon login is just another form of a regular user:pass login. In other words, please don't put in extra logic to prompt only if username=="anonymous".

*** Bug 136287 has been marked as a duplicate of this bug. ***

This is netwerking, not password manager. Reassigning.

gagan nsbeta1+'d this, but I have no too much uni work over the next few weeks, so trudelle moved it ->gagan if Netscape wants this for its release, else please reassign back to me for 1.1alpha. Cyrus: The problem is that ftp does not distinguish between 'login failed' and 'too many users'. We need to pop up a dialog which reflects this, _and_ gives us the option to retry with anonymous logins, or with user/pass.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.

is this a duplicate of another bug?

It could be construed as a duplicate, but I'd like to leave it open. I'm about to read all the FTP bugs in a row, so I'll do a massive cleanup soon.

*** Bug 152750 has been marked as a duplicate of this bug. ***

If I have encountered a new problem or picked the wrong one to update I apologize. We have a large customer who currently uses NN 4.79 for all their work including FTP. They did a test of Nav 6.2.3 this past weekend and FTP failed (at least to get to our site). Our customers are not allowed to use "anonymous" (don't know why except we use m$ windoze everywhere - unfortunatly). The following works for NN 4.79 (and you are free to test as much as you wish) ftp://mainstar.com\customer:4ms390use@ftp.mainstar.com The user is "customer" and the password is "4ms390use" In NAV 6.2.3 and Mozilla 1.0 Build 2002053012 we receive an ALERT box with "530 user anonymous cannot login" I tried with and without the password, with and without the backslash separating the domain and userid. We did show the user they could use DOS command line (worked well) or any number of FTP clients. The following also did not work ftp://ftp.mainstar.com interestingly enough the above command in Opera brought up a dialog box for username and password. Thanks.

That's something else. Filed bug 155223.

Probably your example uses anonymous b/c there is no username between "ftp://" and the hostname..." We'll discusss this more in the new bug...

Nominating for nsbeta1: it's not really a feature, it would just make ftp "smarter".

Argh. I just ran into another testcase for this bug ... it'll throw a 530 like Comment #39 above: ftp://ftp.nikhef.nl/pub/atari/games/larn/larn12src.arc I actually have to hack this to be: ftp://anonymous:lar@@ftp.nikhef.nl/pub/atari/games/larn/larn12src.arc in order to work, minimally, so as not to give a complete email address. It's odd that the server has no issue with anonymous user logins, it just doesn't like a password of 'mozilla@example.org' -- and there's no way for me to set a new default anonymous password. Aargh! This is with a Nightly, Build ID: 2002090608.

If you are wanting to just change your default anonymous password, you can change that in: Preferences | Advanced - "Send this email as an anonymous password"

Stupid, stupid, stupid me. I swear I went looking up and down the prefs tree for just such a thing at 3am this morning and convinced myself I couldn't find it. Fatigue. Panic over the goofy error. Where's the "takeback" option...

I don't like the location either, but we have only one FTP pref in the whole product. Get this, the pref is called "advanced.mailftp" in prefs.js.

Umm this isn't fixed afaict. There is still not username/password prompting. I think this bug warrants something like comment #23.

re: comment #46 ... [topic class="off"] I was really tired, but the pref is not ideally located (or cetgorically titled, note the box "Features that help interpret web pages" -- uh, OK). I blame lack of sleep at the time, but you raise an interesting point. Maybe I can comb bug posts to see whether there are other FTP prefs as enhancements or bugs that could be grouped. Of course, given bug 167289 I wonder where I'll post it? :) [/topic]

Aaron: I messed that up. Thanks for catching it.

*** Bug 179561 has been marked as a duplicate of this bug. ***

*** Bug 179561 has been marked as a duplicate of this bug. ***

*** Bug 180206 has been marked as a duplicate of this bug. ***

This bug makes accessing non-anonymous ftp servers a pain in the butt. IE does this right.

-> defaults Fix it in chimera :) Strictly speaking, isn't this something that docshell does?

not sure how it was fixed in chimera.

It wasn't fixed in Chimera. ;)

that is what i thought; thanks for the confirmation. :-) I am moving this bug out.

("Fix it", not "fix in", or "fixed in"...)

oh it was a command. :-)

This is an IE-parity issue; I think it's a little more important than "Future", but that's just me.

*** Bug 184907 has been marked as a duplicate of this bug. ***

Simon's last point is especially true if you are trying to surf a user-access only FTP file tree to use composer. This means you have to keep hacking your URL to include at least your username, if not password as well. Or you have to use password manager. One of my new test servers presents file space in this way, and naviagation takes forever.

adt: nsbeta1-

I just posted the following to the netscape.mozilla.user.general newsgroup. It turns out that I have run into this bug, still not fixed. Trying to go to an FTP site for which I have been sent by e-mail a URL in the form ftp://ftp.xxx.org, a username and a password. I click on the URL hyperlink and get an Alert message "530 Login incorrect." Hardly surprising as I haven't specified the username and password. At this point IE gives me a login box; and Mozilla does this with HTTP sites which require a login. Is there at this point a way to get a login box from Mozilla? Or simply to get the username into the URL? I think there is a syntax for adding the username to the URL, but it doesn't seem to be what I thought it was (ftp://ftp.xxx.org:username), and it is hardly reasonable to expect users to know this syntax. Then a bit later: I did get into the site in the end by using the format ftp://username:password@ftp.xxx.org. But I had to do a Google search to find an example of this format. And it doesn't exactly keep the password secure as it now appears in plain text in my dropdown list of URLs.

nominating again

Whoa! If the user enters a url as ftp://username@ftp.xxx.org (without password), then he/she gets prompted for a password. If a user enters a url as ftp://anonymous@ftp.xxx.org (again without password), the he/she does _not_ get prompted for a password. So, there are really two issues: 1) FTP code is artificially checking if username == "anonymous" and treating "anonymous" specially. 2) The dialog box should allow BOTH username and password to be edited. A temporary solution for this would be to simply rephrase the dialog's text so that the user knows how to re-type the url to include the username. This bug (#124561) can be closed even if issue 2 cannot be fixed right away as long as issue 1 is fixed.

Cyrus' temporary fix is a step in the right direction but still has serious problems. For when the dialog box comes up the text in the URL box is not the URL of the ftp site I am trying to access but still whatever URL the window was previously pointing at. So what I would have to do in this case is: go back to the original hyperlink to the ftp site which I clicked (in the form ftp://ftp.xxx-xxxxxxxxxxxx.org, but it could be much longer), copy the link location (which might not be what appears on the screen, so I need to know what I am doing to copy the link location) into the URL box, go back to the original hyperlink, find the username and copy that, then paste that and the @ sign into the correct place in the URL box. OK as a workaround perhaps, but not as a proper solution which would allow this bug to be closed.

*Sigh* Don't confuse the issue Peter. :) The (wrong) logic that makes "anonymous" special needs to fixed first. THEN someone can tackle the dialog (see also comment #23) - a dialog box, with or without modifications, does not (and will not) appear as long as the above mentioned logic issue isn't resolved first.

Cyrus, maybe I misunderstood you. When I click my hyperlink, I do (but only after quite a long time) get a dialog box, the Alert message "530 Login incorrect." I thought this was the message which you planned to correct e.g. by adding "The correct syntax is ftp://username@ftp..." That is the fix which I didn't like. Also you suggested that the issue would be closed when a problem with anonymous login is fixed, but that would not close the bug for me as my problem is not with anonymous login. Anyway, I'm not sure that the fix to anonymous login is appropriate. URLs for anonymous login sites are commonly sent out as hyperlinks to just ftp://ftp.site.com. Users should not have to edit that to insert "anonymous@" when they actually want anonymous login. So I suggest two sensible alternatives when the user clicks on a hyperlink like ftp://ftp.site.com, with no username: 1) Try anonymous login, and if that fails bring up a dialog box, as in comment 23; or 2) Immediately bring up a login dialog box with the password field blank and the username "anonymous" already filled in, but selected so that typing a new username immediately overwrites it.

special casing anonymous was a feature request: http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp#2212

Doug, that can't be it. Line 2212 is in the ::init(). Line 2212 only explains that explicitely using "anonymous" in the url (also) causes mAnonymous = TRUE. It doesn't explain why a failed anon login _doesn't_ result in a username/password prompt. Reading S_user/R_user shows it should. The bug is somewhere after ::R_user (lines 1042-1047: sees reject, sets mAnonymous=FALSE) returns FTP_S_USER. The way I read it, the ::Process switch() loop then calls ::S_user again, and this is where something is going wrong. Either a) ::S_user is not being called again? b) mAnonymous is back to TRUE? (would explain why anon login failures take so long for the user to see the failure). c) some other wickedness is happening in password manager when username == "anonymous"? Either way, no username/password prompt is seen if the username (either by default or because the user entered it so) is "anonymous". All I get is a "530 Bad username or password" alert. No prompt.

err, anon login failures taking very long before the user sees the failure can also be explained by hosts that intentionally delay on login failure as part of a strategy to limit brute-force attacks.

re: ftp://anonymous@host/ I filed that bug. If you want to change the behavior, reopen that bug. It was a toss up between two behaviors, although I did prefer the second choice: http://bugzilla.mozilla.org/show_bug.cgi?id=196286#c2

the ::init change (bug #196286 and the resultant mod at line 2212) is fine. No problem there. After having slept on it, I think the problem is in one of ... -------------------------------------------------------- 1) In R_user the clause 1036 } else if (mResponseCode/100 == 5) { 1037 // problem logging in. typically this means the server 1038 // has reached it's user limit. 1039 return FTP_ERROR; is faulty. It does NOT (necessarily) mean limit reached. As Bradley pointed out in comment #33 it can ALSO mean "bad username". Consequently, if the server returned "530 Bad username or password", Mozilla will not fall into the next clause 1040 } else { 1041 // LOGIN FAILED : //go back to S_user to prompt for //username/password and retry. return FTP_S_USER; 1050 } This is, as I said in comment #23, because (or inspite of) the 'bad login' and 'too many users' error codes are identical, Moz should be prompting for a new username/password. Only two trivial changes are required to solve this: a) Change R_user to let 5xx errors fall through and return FTP_S_USER. Remove lines 1036..1039 b) Change S_user such that the first two arguments of the call to mAuthPrompter->PromptUsernameAndPassword() reflect the reason why the user is being prompted [again]. nsAutoString aPromptStr; const PRUnichar *dialogTitle = nsnull; //default const PRUnichar *dialogText = formatedString; if ((mResponseCode / 100) == 5) { // Prepend dialog text with "{host} said: \"5xx blah blah\"\n\n". // Like the Alert, "said: "5xx blah blah"" isn't localizable. dialogText = ... // change dialog title to '5xx blah blah' too. aPromptStr = NS_ConvertASCIItoUCS2(mResponseMsg); dialogTitle = aPromptStr.get(); } rv = mAuthPrompter->PromptUsernameAndPassword(dialogTitle, dialogText, : -------------------------------------------------------- 2) nsFtpConnectionThread.cpp expects this: client: send "anonymous" server: send "bad username" client: prompt for username+password. go back to send_user and this is what can happen: client: send "anonymous" server: send "ok" client: send password server: send "bad username or password" client: if (mAnonymous) fail (no sense prompting _only_ for password). else prompt for password (only) because username ok. go back to send_pass In other words, Moz is expecting the server to _immediately_ reject bad usernames, and this won't happen with servers that won't let you know whether the username (alone) is or isn't valid. Incidentally, because only password is prompted for, if the username was mistyped, the user will not get a chance to retype it. --------------------------------------------------------

*** Bug 215964 has been marked as a duplicate of this bug. ***

Cyrus: are you going to create a patch for this?

*** Bug 233356 has been marked as a duplicate of this bug. ***

*** Bug 237935 has been marked as a duplicate of this bug. ***

*** Bug 240856 has been marked as a duplicate of this bug. ***

Bug 24867 was recently fixed and now Mozilla has a UI for uploading files to FTP. This is a good reason to bump the priority of this bug a notch, as Mozilla is probably going to be used more often to handle FTP. Prog.

excellent, im glad to see this old bug being forwarded a bit

On the ftp server i tried, sending anoymous as the username doesn't fail yet. It only fails after sending the password. So, that makes option 2) from comment 74 a likely candidate. The patch tries to do that. If login failed for anonymous, prompt for password. (Maybe the check for return codes needs to be narrowed down to only 530?)

Comment on attachment 151384 [details] [diff] [review] first try i hope this is the right thing to do...

Well, what do ya think guys? I'm sure many would appreciate this for the upcoming releases...

Comment on attachment 151384 [details] [diff] [review] first try ok... looking at S_user and R_user this does seem to be the right thing. S_user seems to leak username & password, I filed bug 253394 for this

Comment on attachment 151384 [details] [diff] [review] first try this looks good. r++ = me.

Comment on attachment 151384 [details] [diff] [review] first try sr=darin

Checked in

(can we assign the bug to the person that fixed this?)

per benc reopen for reassignment

re-resolve as fixed with a non-future milestone

*** Bug 258908 has been marked as a duplicate of this bug. ***

*** Bug 263014 has been marked as a duplicate of this bug. ***

*** Bug 271765 has been marked as a duplicate of this bug. ***

*** Bug 277781 has been marked as a duplicate of this bug. ***

*** Bug 279843 has been marked as a duplicate of this bug. ***

*** Bug 286510 has been marked as a duplicate of this bug. ***

*** Bug 284031 has been marked as a duplicate of this bug. ***

*** Bug 294785 has been marked as a duplicate of this bug. ***

*** Bug 308637 has been marked as a duplicate of this bug. ***