Closed Bug 129565 Opened 18 years ago Closed 18 years ago

HTTP publish does not work if password left blank

Categories

(Core :: Networking: HTTP, defect, P2, major)

defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: darin.moz, Assigned: darin.moz)

References

()

Details

(Whiteboard: publishing)

Attachments

(2 files)

HTTP auth not using username:password supplied in URL.

probably a regression from bug 124042.
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: mozilla1.0, nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla1.0
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) :-(
Keywords: regression
Whiteboard: publish
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:foo@unagi.mcom.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!
Keywords: regression
Whiteboard: publish
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.
Keywords: 4xp
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.
Attached patch v1 patchSplinter Review
Whiteboard: publishing
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.
Attachment #73246 - Flags: review+
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

sr=kin@netscape.com
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.