Brian 'netdragon' Bober Reporter
	Description • 24 years ago

Basically if you do this:

http://name:password@www.yahoo.com

or 

ftp://name:password@ftp.rpi.edu

it would be nice to put * - stars in place of the password in the url dropdown. 
It would be especially good for universities where many people share the same 
computer.

	neil@parkwaycc.co.uk
	Comment 1 • 24 years ago

I would like to see the password removed immediately from all entered URLs
(although that would require the password to be saved somewhere else).

	Aaron Kaluszka
	Comment 2 • 24 years ago

I think this should be a preference because I personally like the way it works now.

	Mitchell Stoltz (not reading bugmail)
	Comment 3 • 24 years ago

What is our current behavior WRT passwords in URLs? Should we be stripping them
out immediately after the initial load and not saving them in history, etc? Or
should we just star them out as Brian suggests?

	Brian 'netdragon' Bober Reporter
	Comment 4 • 24 years ago

I wouldn't like it if the user:password was removed from the url line when
placed in it. Currently, the user:password is left on the line. It would also be
confusing WRT to the dropdown box if it was stripped. You wouldn't know if it
was already set to login. Although, it might be bad security to even put it in
the dropdown box. Maybe the password should be totally left out when placed in
the dropdown box.

For instance:

http://blah:blah@www.yahoo.com/
 
1) would turn into for the url box

http://blah@www.yahoo.com

or 

http://blah:****@www.yahoo.com

2) and would turn into for the dropdown box

http://blah@www.yahoo.com

I believe doing the first option would be the best for #1. It would keep
consistency.

As for in the history, it leaves the password intact too. 6/25 build.


<offtopic>
Btw: I can't get either FTP or http authentication to work using this method. In
fact, FTP doesn't work at all. Are these known issues?</offtopic>

 

	Doug Turner (:dougt)
	Comment 5 • 24 years ago

to alec.

	Alec Flett
	Comment 6 • 24 years ago

->URL Bar, still me.

	Alec Flett
	Comment 7 • 23 years ago

reassign url bar bugs to new owner..

	benc
	Comment 8 • 23 years ago

I haven't worked through all the RFCs, but the first convention is illegal anyhow.

	Blake Ross
	Comment 9 • 23 years ago

Joe was dying to have these bugs. Who am I to say no?

	Benjamin Mucci
	Comment 10 • 23 years ago

Should not be set to Future IMO. It's a critical security issue.

	Adam Hauner
	Comment 11 • 23 years ago

This is not enhancement, this is really security bug. Brian, could you set any
other target?

	Adam Hauner
	Comment 12 • 23 years ago

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

	Brian 'netdragon' Bober Reporter
	Comment 13 • 23 years ago

Adding the mozilla1.0 keyword and changing the milestone to 1.0 to see if this
gets any support from drivers.

	Adam Hauner
	Comment 14 • 23 years ago

Brian: You can't change Target Milestone, it's Joe Hewitt's target. Setting back
-> Future.
(Joe: If I'm wrong, correct me)

	Boris Zbarsky [:bzbarsky]
	Comment 15 • 22 years ago

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

	Nicholas Bebout (nb84@evansville.net is my new email)
	Comment 16 • 22 years ago

I think that it should not save the passwords in history or in the url bar.

It is insecure for them to be saved like that.

	Nicholas Bebout (nb84@evansville.net is my new email)
	Comment 17 • 22 years ago

Sorry for the spam...
Changing CC to my new email addy..

	Alon Altman
	Comment 18 • 22 years ago

If I'm not wrong, the patch for bug 130327 fixes this bug as well.

	Jo Hermans
	Comment 19 • 20 years ago

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

	tevion48x
	Comment 20 • 20 years ago

I read and read and read but didn't find any solution for my problem which I
posted in bug number 279296.

Can someone please tell me how to teach Firefox 1.0 NOT to remove the username
and password from the URL?

	OstGote!
	Comment 21 • 20 years ago

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

	Daniel Veditz [:dveditz]
	Comment 22 • 20 years ago

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

	kstahl
	Comment 23 • 20 years ago

I don't like this behaviour at all. Seems like a big security risk to me. 

Requesting blocking 1.1.

	Philip Chee
	Comment 25 • 13 years ago

Forward dupping to Bug 146289 since there is a patch there.