Netscape 4.x has a good feature which is missing in Mozilla. When you enter url like http://email@example.com, and host requires authentication password dialog appears. In Netscape 4.x this dialog had already username filled in, all yiou had to do was to enter password. This was very usefull when such url was stored in bookmarks. But now you must reenter username and password.
must be networking, right?
Assignee: hangas → neeti
Status: UNCONFIRMED → NEW
Component: User Interface: Design Feedback → Networking
Ever confirmed: true
OS: other → All
QA Contact: mpt → tever
Hardware: PC → All
Summary: Password dialog with prefilled username → RFE: Auth dialog should be prefilled with username when using http://firstname.lastname@example.org
Changing component to HTTP
Assignee: neeti → darin
Component: Networking → Networking: HTTP
*** Bug 114254 has been marked as a duplicate of this bug. ***
*** Bug 139851 has been marked as a duplicate of this bug. ***
In the dup bug I filed, bug 139851, I suggested this should happen for FTP also. I notice this bug is under Networking::HTTP. Would the work done in Networking::HTTP get us FTP support too?
nope, this bug would have to be solved individually for FTP.
Status: NEW → ASSIGNED
*** Bug 166649 has been marked as a duplicate of this bug. ***
*** Bug 196090 has been marked as a duplicate of this bug. ***
*** Bug 202544 has been marked as a duplicate of this bug. ***
Rather than open a new bug, and based on comments I've seen in other bugs, this is the "base bug." Usernames and Passwords are not properly transmitted by Mozilla if the URL contains a cgi query. I have seen this in 1.4 (on Windows 2000 and Linux) and now 1.5 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Debian/1.5-2). AFAICT, Mozilla is not remembering the username:password pair and retransmitting. Procedure: 1. Go to site that requires authentication, and use username/password in URL: http://username:email@example.com/needs_auth/some_page.html 2. The attempt to get some_page.html will be successful. 3. Attempt to click on link on some_page.html. This will work. 4. Attempt to click on a page with a CGI URL that ends in the form "cgi?data". I get a dialogue box asking for the username/password. I postulate some wacky interaction between the CGI query form of the URL and the "get username/password and send it again" section of the code.
Summary: RFE: Auth dialog should be prefilled with username when using http://firstname.lastname@example.org → Auth dialog should be prefilled with username when using http://email@example.com
There are two problematic areas here: 1. Necko doesn't remember the username. The code is at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp&rev=1.213#2227 It clears the authentry if it couldn't log on with it. By doing that, it forgets the username. so it doesn't hand the username to the promt 2. wallet tries to get the username + password from the saved data. After doing that, i copies over the username strings even if there was no stored username. So, the username won't appear in the dialog. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/wallet/src/singsign.cpp&rev=1.245#2712
(In reply to comment #11) > There are two problematic areas here: isn't the main problem that nsIAuthPrompt has no way to pass in a username to fill into the dialog?
14 years ago
Depends on: 265780
I took a gander at the source for the Necko/Moz API a couple years back trying to figure out a solution... it indeed seemed to be an overwhelming task to figure it out -- this feature (pre-filling the username) (standard syntax and behavor in other agents) seems so simple after all.. The orginal authors would probably do 2-10 time better figuring this out than I (or most outsiders?)... have they moved on to other things, or?
bug 265780, which this bug depends on, will make this pretty easy, I believe.
Firefox no longer prompts for the user and password if you pass them on the URL, it just asks for confirmation, and has been like this for a while.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.