Open
Bug 32761
Opened 25 years ago
Updated 2 years ago
URL: Passing user id and null password via HTTP ("user:<NULL>")
Categories
(Core :: Networking, defect, P5)
Core
Networking
Tracking
()
NEW
People
(Reporter: yoel, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-would-take])
From Bugzilla Helper: User-Agent: Mozilla/4.72 [en]C-DIAL (WinNT; U) BuildID: 2000022820 Mozilla does not respect a null password in a URL, i.e. when there is no space between the colon and @ sign. This RFC states that if a colon exists then a password is being supplied. Here is the RFC that discusses this format. ftp://ftp.isi.edu/in-notes/rfc1738.txt In the 4.0x Communicator code when a user passed a null password in a url the userid and password were sent to the server. http://user:password@host In 4.5+ this was changed and Communicator no longer sent the URL to the server, but prompted the user for the password. This is going to be fixed, see 388773 (Netscape Only) Reproducible: Always Steps to Reproduce: 1.setup a server with a user db that allows null passwords, I think MS SQL and Access allow this 2. Type in a URL to that server including the userid and null password http://user:@host Actual Results: An HTTP Authentication dialog was presented to me Expected Results: I should be able to acces the site
Comment 1•24 years ago
|
||
This bug should be marked VERIFIED, but I don't have permissions. I tested this against my web site with NB 20000412. I used a URL like http://test:@www.site.com and was shown a username/password dialog instead of being let into the site. I could not verify that other browsers would work because Netscape 4.72 also will not allow NULL passwords to be passed. BTW, I could not login with a NULL password either via embeding it in the URL nor by using the username/password dialog in either 20000412 or NN 4.72.
Comment 3•24 years ago
|
||
Greg Breland - are you saying this bug is fixed, or that you can definitely see it? Gerv
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•24 years ago
|
||
I can confirm this is happening on mozilla with ftp accounts. Something like ftp://user:@host/ will present you the box to type in the password, but the empty password is not accepted. You can not log into such an account, which is not so bad, since it forces people to put passwords on it. ;)
Hmmm... I don't think we check for empty passwords inside necko. Seems like wallet problem. over to morse for investigation.
Assignee: gagan → morse
Comment 6•24 years ago
|
||
It's not a single-signon problem. I'm just the messenger here -- if you called me to put up a dialog, then that's what I do (unless of course I already find an entry in my saved-password database). If you didn't want a password dialog, then you shouldn't have called me. I don't do any parsing of the url string to determine if it contains a username and/or password. I used to parse the username out of the url but warren felt that was the wrong thing to do and he removed all the parsing code from single singon.
Assignee: morse → gagan
Comment 7•24 years ago
|
||
Forget my last comment about ftp on this problem. Non-anonymous ftp access needs a password by definition, there are no private ftp accounts without password.
Comment 8•24 years ago
|
||
Maybe the problem here is that we can not tell the difference between no password (null) and empty password ("") when this is stored in an AutoString or something similar.
Comment 12•22 years ago
|
||
RFC1738 is long outdated The latest is RFC2396 The format it uses is <userinfo>@<host>:<port> and not <user>:<pass>@<host>:<port> So maybe you should try not to put the : before @ and see what happens.
Comment 13•22 years ago
|
||
Alex, I think the point is this: Note that an empty user name or password is different than no user name or password; there is no way to specify a password without specifying a user name. E.g., <URL:ftp://@host.com/> has an empty user name and no password, <URL:ftp://host.com/> has no user name, while <URL:ftp://foo:@host.com/> has a user name of "foo" and an empty password. This is valid even in the newer RFC: userinfo = *( unreserved | escaped | ";" | ":" | "&" | "=" | "+" | "$" | "," ) "username:" would be a valid userinfo. re: andreas' comment, I recall (but did not check today) that ftp servers do not all require passwords, some require only usernames.
Component: Networking: HTTP → Networking
QA Contact: tever → benc
Summary: Passing user id and null password via HTTP URL → URL: Passing user id and null password via HTTP
Summary: URL: Passing user id and null password via HTTP → URL: Passing user id and null password via HTTP ("user:<NULL>")
Comment 14•21 years ago
|
||
does this bug still exist with moz 1.4 alpha?
Comment 15•20 years ago
|
||
No response in over a year. Resolving WFM.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Comment 16•20 years ago
|
||
I missed darin's comment. This still happens in 1.6f.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•18 years ago
|
Assignee: darin → nobody
Status: REOPENED → NEW
QA Contact: benc → networking
Target Milestone: Future → ---
Updated•8 years ago
|
Whiteboard: [necko-would-take]
Comment 18•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P3 → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•