124480 - When opening ftp connection to remote URL, missing username should prompt for username and password (nsIAuthPrompt::promptUsernameAndPassword)

Status: VERIFIED INVALID

(Core Graveyard :: Networking: FTP, defect)

Description

[Charles Manske]

During pulishing, we build an nsURI object and fill in username and password.
We save the document using nsIWebBrowserPersist interface.
When the username is empty, we get a "Login incorrect" message, even though
we have implemented the promptUsernameAndPassword method implemented for both
nsIPrompt and nsIAuthPrompt. 
Note that if username is supplied but password is empty, we do get the call to
the nsIAuthPrompt::promptPassword dialog.
Kathy: please reassign to the appropriate network engineer.

Comment 1

[Darin Fisher]

i'm not completely following the problem here.  can you provide sample URLs with
expected/actual browser behavior?  thx!

Comment 2

[Charles Manske]

Darin: We are building an nsIURI object for publishing via 
nsIWebBrowserPersist::SaveDocument.
If we supply ftp://[e-mail] as the URI spec, our 
nsIWebProgressListener::promptPassword() method is called and we can get 
the password.
If we supply ftp://ftp.foo.com as the URI spec, it seems our 
nsIWebProgressListener::promptUsernamePassword() method should be called,
but it isn't. Instead, we get a "Login incorrect" alert dailog.
Using http push to publish doesn't prompt for anything, including missing 
username and/or password or any error conditions!
But it does publish correctly if the URI is http://user:[e-mail]
and the "user" and "pass" is correct.

Comment 3

[Darin Fisher]

cc'ing bbaetz for FTP problem.

cmanske: can you generate a HTTP log for the HTTP case?  set these variables
before running mozilla:

 set NSPR_LOG_MODULES=nsHttp:5
 set NSPR_LOG_FILE=c:\http.log

if you can attach the generated log file that would help. thx!

Comment 4

[Charles Manske]

Attachment: HTTP log when no password was supplied

In this case, there was no prompt for the password.
Transfer of file failed.

Comment 5

[Charles Manske]

Attachment: HTTP log - successful transfer

In this case, neither the username nor the password were supplied,
but it *did* trigger the promptUsernamePassword dialog, and it
succeeded in transfering the file!

Comment 6

[Bradley Baetz (:bbaetz)]

The ftp side of this is a dupe of bug 124561, also see bug 114118.

Comment 7

[Charles Manske]

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

Comment 8

[sujay]

cc: Tucson

Comment 9

[Charles Manske]

Note: HTTP transfer is now working. Only FTP seems to have a problem.
Should we close this and concentrate on bug 124561? For now, I've made that one
a blocker for this bug.

Comment 10

[sujay]

lets wait to close this out after the blocker is fixed..

Comment 11

[sujay]

nominating EDITORBASE...already marked nsbeta1+

Comment 12

[benc]

Is this change going to visibly affect non-composer behavior?

If not, then I'd like to have composer qa take this from me.

Either that, or un-duplicate Bug 127094, and make it a duplicate that Composer
QA can verify.

Comment 13

[Kathleen :Brade]

This bug is not a "Composer" bug.  The browser should also have this behavior
(if Composer has it).

Comment 14

[Darin Fisher]

umm.. but isn't your solution entirely specific to publishing?

Comment 15

[Kathleen :Brade]

This particular bug does not have a solution; at least not yet.
Composer is working around this issue in a different way.

My understanding of this bug is that if anonymous login fails for some
reason(s), we should prompt the user to authenticate.

If anyone has some suggestions on which particular response codes should cause
the  authprompt to come up instead of an alert (or in addition?) that would help
get this bug resolved sooner.  Otherwise, it'll sit on my list with a very low
priority.

Comment 16

[Charles Manske]

For Composer publishing, I have reduced this problem by detecting when username or 
password is missing and putting up the promptUserNameAndPassword dialog ourselves.
This will help a lot, but still doesn't fix the case when there's an error in
either the username or password; in those cases, it will still fail instead of
reprompting to let user corrrect them.
This is only a problem when using FTP. HTTP does lauch proper prompt dialogs.

Comment 17

[Bradley Baetz (:bbaetz)]

Such an error code does not exist; thats the problem here.

Comment 18

[benc]

brade: my point is that this either works (http) or existing bugs cover the
failures (in ftp). I think we are in general agreement that the ftp module is
currently too heavily "browser-only" oriented. 

The only reason this bug would exist and be treated separately is to meet the
needs of composer. And in that light, the best person to QA your bug would be a
composer QA.

Comment 19

[Kathleen :Brade]

BenC--I am unaware of which ftp bug already covers this issue.  Please duplicate
appropriately if you know of such a bug.

clarify summary and component to be ftp-specific

Comment 20

[Charles Manske]

It has now become apparent that Composer is totally screwed by the FTP behavior
of assuming anonymous login if username+password is missing or fails.
We simply cannot edit FTP urls directly with this problem.
In the Publish dialog (Settings Panel) or Publish Settings dialog, the user can
supply a HTTP address that is the alias for the FTP address. If that is not
supplied, we get "login failed" when publishing files (see bug 133823)
This is because after publishing, we change the URL of the page to the ftp
address, but without the username+password, and BOTH are needed to successfully
load the page. We could insert the "username:password@" into the document URI,
but I think that is very evil. You NEVER want the password to show in plain text,
of course, like in the window title and many other places that access the 
document's location.href. So after publishing like this, further attempts to
save changes will result in constant "login falied" alerts.

Comment 21

[Bradley Baetz (:bbaetz)]

Well... I'd consider publishing to an ftp-only password protected site to be an
extreme edge case.

Can't you just require an http alias? I'd imagine that that is what 95% of
people want, and probably 99.9% of people who check the option to use abolute
urls would expect that. Or am I missing a use case?

Comment 22

[Charles Manske]

I agree that most users should be publishing to sites that have an HTTP address
for their pages, but are using FTP with username + password. I am doing my best 
to make that the encouraged behavior.
But I'm not sure what you mean by "check the option to use ab[s]olute urls" 
What option?

Comment 23

[Bradley Baetz (:bbaetz)]

last time I looked, there was an option to make <img> urls relative. If you
don't have that, then its absolute, and putting a link to the ftp site isn't
what is wanted, anyway.

Comment 24

[benc]

brade: this behavior was what I was essentially talking about in bug 124561.

bbaetz: The ftp publishing you are talking about is hardly an edge case, it's
one of the best features of composer. In fact, for a fair number of people I
know, the lack of a working publish button is what keeps us using Comm 4. 

Assuming this behavior is desirable, how can we structure the code to do what
composer needs? Is it possible that what is needed is some nasty url-hiding
magic (that is done for wyciwyg:) that has the literal ftp URL and then a
sanitized ftp URL for user display? (has a feeling this won't work b/c of links
in the published document).

(not blaming the composer people here, argued with at least one PM about not
having this for the 6.0 releases, I really want this to work!)

Comment 25

[Charles Manske]

I actually discovered something important that fixes the "Login incorrect" 
harassment discussed in bug 133823. Check out that bug later for fixes.

Comment 26

[Kathleen :Brade]

Looking at the code, I think I see what the problem here is.  In S_user(), we
have "if (mAnonymous) ... append 'anonymous' to the command else if the username
is empty, prompt for username and password"  mAnonymous is initialized to true
and set to false based on a username existing in the uri.  I think the code
around the PromptUsernameAndPassword call is only called in the edge case that
anonymous login fails.  

I'm not sure if we should address this or not since sometimes in the browser, we
just want to be "anonymous" and not login.  For publishing we do want the user
to provide a username or be prompted for it in most cases.

I vote for invalid, wontfix or Future.
Other opinions?

Comment 27

[Kathleen :Brade]

marking this as invalid per my argument in earlier comment

Comment 28

[benc]

VERIFIED:
I ultimately don't understand how this bug ended, so I'm verifying it.

In the future, please don't morph bugs, create one per component...

In the case of publishing, basically problems in every protocol handler should
be treated separately (ftp, http, https), even if they are appearing in
parallel. If there is a root cause, file a bug there, and mark them as
dependent. That's the best way to get clear test results when you fix and want
to ship.

I know some people are slack about this, but for my components, I'm going to be
more pushy about this because the older system just didn't work.