Closed Bug 129565 Opened 18 years ago Closed 18 years ago
HTTP publish does not work if password left blank
HTTP auth not using username:password supplied in URL. probably a regression from bug 124042.
I have only tried ftp publishing since Darin landed; sorry mcs tried http earlier and he had problems (had to go back to 4.x) :-(
To test, use Composer's publish dialog: "File | Publish As". Use existing site if you have one, else enter in the publishing data in the "Settings" panel. Be sure to enter the username and password in the Settings panel. Click Publish -- you should not get the username/password prompt dialog.
actually, this bug description is INVALID or at least not specific enough. if i modify the URL given above to be: http://foo:email@example.com/tests/auth-tests/basic-realm1/ then it works. it fails to use the username:password from the URL if a redirect occurs, because the username:password is not forwarded to the redirected channel. this is normal behavior. i'm not sure that it is a bug because forwarding the username:password could be considered a security violation. i'm going to leave this bug open because cmanske says he's seen a problem like this with PUT requests. please supply a testcase and/or provide more details about how i can repro the problem. thx!
cc'ing bbaetz since this has been reported as a problem w/ FTP URLs as well.
Darin--create a new page in Composer (Tasks | Composer) type "foo" choose File | Publish As... click on the site settings tab and setup publishing for blues.mcom.com (or whatever server you happen to be on) my Publishing location is: http://blues.mcom.com/users/brade/publish/ leave edit field below that empty you can fill in username and password or not switch back to publish tab enter a file name: foobar.html Click publish I expect that publishing would succeed if no typos. If I don't provide a login and password, I expect to be prompted for them. If I don't provide a password, I expect to be prompted. I am not being prompted. Publishing (HTTP PUT) is not succeeding.
also note: This is a regression for me; I have successfully published to blues in the past (via both ftp and http) I haven't tested ftp lately (it has a different url from the one above)
ok, so i'm unable to repro the problem [linux build 2002-03-07/08] when i supply a username and password in the publish dialog. location = http://blues.mcom.com/users/darin/publish/ brade: the problem you are describing about not being prompted is very different from the problem cmanske described... he said that when the username:password is specified in the URL string that the user would be prompted. i cannot repro that problem. will try the problem you describe now.
ok, so w/ a trunk CVS build from yesterday, i tried publishing w/o specifying my username or password in the publish dialog. i was prompted to enter my username and password. when i left out the password but specified a username in the dialog, it failed to prompt.
and then following that... i entered the correct password, and it still failed to publish correctly. now, looking at the transaction: 1024[809bc60]: http request [ 1024[809bc60]: PUT /users/darin/publish/foopy2.html HTTP/1.1 1024[809bc60]: Host: blues.mcom.com 1024[809bc60]: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020221 1024[809bc60]: Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 1024[809bc60]: Accept-Language: en-us, en;q=0.50 1024[809bc60]: Accept-Encoding: gzip, deflate, compress;q=0.9 1024[809bc60]: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 1024[809bc60]: Keep-Alive: 300 1024[809bc60]: Connection: keep-alive 1024[809bc60]: Authorization: Basic ******** 1024[809bc60]: Content-Length: 227 1024[809bc60]: Content-Type: text/html 1024[809bc60]: ] XXX Damage rectangle (57,3477,5150,39) does not intersect the widget's view (0,0,5149,3458)! 1026[810e290]: http response [ 1026[810e290]: HTTP/1.1 404 Not found 1026[810e290]: Server: Netscape-Enterprise/3.6 1026[810e290]: Date: Fri, 08 Mar 2002 19:18:07 GMT 1026[810e290]: Content-Type: text/html 1026[810e290]: Content-Length: 207 1026[810e290]: ] it's unclear why this is failing. i don't understand why the server is failing with 404. there does not appear to be anything wrong with the request... or if the auth tokens are incorrect... the server should say so with a 401 response. there is definitely something wrong with the server.
interesting....when you leave out the password, no prompt..this could be what is causing bug 127109 (we get into a state where we can't publish anymore; workaround is to exit netscape and relaunch, then re-publish)
and the server returned the following HTML: <TITLE>Not Found</TITLE><H1>Not Found</H1> The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it.
after some investigation, it seems like we can work around this bug in netscape enterprise server as follows: when password is missing, instead of sending 'user' we should send 'user:' this is what netscape 4x does.
revising summary to reflect the real problem. if there's a problem w/ FTP publish, then we need another bug.
Summary: HTTP auth not using username:password supplied in URL → HTTP publish does not work if password left blank
*** Bug 127109 has been marked as a duplicate of this bug. ***
i checked with the HTTP/1.1 spec for basic auth, and it seems to imply that the ':' is mandatory. see the last paragraph of RFC2617 section 2. of course, that still doesn't justify the meaningless 404 error. it should at least send a "400 bad request" if it is going to be so strict :-(
Once you get into this state where you can't publish(due to blank passwd. and even re-entering passwd second time), the workaround is to exit netscape and relaunch and re-publish with passwd. Then publish works. Just wanted to declare this. I know it may appear obvious to some.
I've been having trouble getting consistent publishing behavior, but after applying the "v1 patch" and publishing to my http://blues/users/cmanske site, I can successfully publish. If I enter both username and password, it publishes successfully w/o any prompt dialogs (which it seemed to be doing yesterday). If I don't enter the username and password in the Publish dialog, Settings panel, I correctly get the prompt dialog to enter bot. If I supply the username, but leave the password blank in the dialog, it prompts with the same dialog and doesn't show the username that I supplied. It should called nsIAuthPrompt::promptPassword, not promptUsernamePassword. That is relatively easy to workaround though, since I can test for "user.value" before launching the dialog and fill in the username input with the username we know, but it doesn't put the focus in the password dialog. I'll attach a log for this last case.
Darin, I'd like to make sure this bug that Charley found gets addressed: Do we need to file a new bug on this ? "If I supply the username, but leave the password blank in the dialog, it prompts with the same dialog and doesn't show the username that I supplied. It should called nsIAuthPrompt::promptPassword, not promptUsernamePassword. That is relatively easy to workaround though, since I can test for "user.value" before launching the dialog and fill in the username input with the username we know, but it doesn't put the focus in the password dialog. I'll attach a log for this last case."
cmanske: actually, the HTTP code can't choose between promptPassword and promptUsernamePassword because for all it knows the username might also be invalid. the first thing it does when no password is specified, is try sending 'user:'... because maybe a blank password is valid. likewise, i'm not sure how the publish code (implementing nsIAuthPrompt, i presume) could prefill with the username. how do you know it is correct? hmm... actually, i guess you can assume it is correct since the user entered into the publish dialog. yeah.. that sounds reasonable to me. you probably want to handle that in a separate bug though.
Comment on attachment 73246 [details] [diff] [review] v1 patch r=bbaetz, if username is never going to be empty (I don't think it will be, but...)
Ok, it is reasonable that HTTP code can't "choose between promptPassword and promptUsernamePassword" (although FTP does), but why doesn't it supply the username it has when it does call promptUsernamePassword? Like I said, it isn't a big deal, we have the information the user entered in the dialog and can fill in the username when we get the promptUsernamePassword request. I'll file a bug for me to do that.
cmanske: because HTTP has no idea if the username is correct (in fact the server told it that it is probably wrong) whereas publish has a slightly better idea since the user already entered their username in the publish dialog. you might say: but HTTP could supply the username because there is a high probability that that would be correct... and you might be right. i'm not really sure. bbaetz: the spec says that basic auth credentials are the base64 encoding of user + ":" + pass... it doesn't say anything about leaving out the ':' if user or pass happen to be empty. so, i think we should always send the ':'.
But if both are empty, then we shouldn't get here, right? Thats my main concern
bbaetz: why? perhaps that is a valid username:password. the spec says that both the username and password can be empty. user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT
Darin--I partially agree with Charley. HTTP should present the "bad" login as part of the prompt dialog (for example, user might have a typo and be able to easily fix it rather than force them to retype the whole thing). Also, it's better for users to see what login/ID caused the failure (imo). Is it too late to land this patch on the 0.9.9 branch?
brade: there might be time to sneak this into the 0.9.9 branch... send mail to drivers? explain why this is important for 0.9.9. i can see pre-filling the username (and NOT the password) that failed being a useful feature, but let's defer that change to another bug.
Comment on attachment 73246 [details] [diff] [review] v1 patch firstname.lastname@example.org
Attachment #73246 - Flags: superreview+
FYI, "v1 patch" works for me. I was able to publish to rocknroll (Netscape Enterprise Server 3.6SP2) using a private Win32 build from today that includes the patch. I left the username and password fields blank in the site settings and I was prompted for username and pwd as expected.
ftp requiring a password is bug 130536. Blank passwords are explictly excluded, and I need to work out if there was a reason before changing it.
Comment on attachment 73246 [details] [diff] [review] v1 patch a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #73246 - Flags: approval+
fix checked into 1.0 trunk
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
verified in 3/20 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.