We currently do HTTP 401 authentication by throwing a modal login dialog, which blocks any use of the browser until the dialog is closed - including closing the dialog. This is annoying, might obscure the source of the dialog, is inconsistent with how we handle other HTTP 4xx errors; not to mention possible DoS attacks with no-authentication-needed sites including a large number of 401ing images (each image triggers a separate password prompt). Also, in the 401ing-image-in-non401-site case, we display all prompts at once (stacked on top of each other), though it is quite likely that all images would need the same password, thus only one prompt would be needed; forcing the user to enter the password separately for all images. (See bug 206351 - however, this is for Firefox/Toolkit, while bug 206351 is for Seamonkey.) There is also no way of logging out/deauthenticating once you've logged in (other than maybe explicitly adding "user:pass@" to the beginning of the URL, which may cause other problems), or even see that you are logged in. Proxy authorization (HTTP 407) is also severely affected; with restarting the browser with multiple tabs open potentially throwing a separate prompt for each tab, or even for each image/media element loaded. Another issue occurs when an user clicks a link on a page in the format "http://user:email@example.com", which also produces an avoidable modal dialog. To fix this, I propose the following changes: -Replace the dialog with a log-in page (similar to the existing "friendly" error page for HTTP 404 and DNS errors). A mockup/concept of the page is attached to this bug. The warning message should change depending on whether the connection is encrypted. The page also needs to indicate whether it is the proxy or the site requesting authentication. On a failed auth, the page can be re-thrown with the "Authentication required" header changed to "Authentication failed". A similar login page can be shown if an user clicks a "http://user:firstname.lastname@example.org"-style link, with the credentials pre-filled in, and a slightly different header/description ("Authentication requested", "You are about to log on to 'My Realm' at http://401site.com"). -Make the password manager capable of remembering credentials entered via the 401 login page. -Handle embedded images needing authentication the same way as missing plugins (icon in place of image + infobar). (I wonder what security implications this may have - maybe we should simply not display such images, as they indicate a misconfigured server. This may interact badly with caching, though - ideas welcome.) -Display URLs of authenticated pages as "protocol://email@example.com/path/to/resource". The user can log out by explicitly removing the "user@" from the URL. (Maybe a more visible logout button is also needed.) -Add credential fields into the proxy configuration dialog, which stores the credentials in the password manager. -If the user sets a proxy with the credential fields empty, then the proxy requests authentication, display the login page. When the user logs in, display the password manager prompt infobar, and if the user saves the credentials, show them in the proxy configuration dialog. -If the proxy has saved credentials, and a master password is set, prompt for the master password on browser startup.
Attachment #405691 - Flags: ui-review?
Severity: normal → enhancement
Component: Password Manager → Networking: HTTP
Product: Toolkit → Core
QA Contact: password.manager → networking.http
Summary: Redesign HTTP 401/407 authentication to use a login page (similar to the 401 "friendly error page") → Redesign HTTP 401/407 authentication to use a login page (similar to the 404 "friendly error page")
I've read some more about the subject, and now I think the "display username in URL" suggestion is not the right thing to do security-wise (think "http://firstname.lastname@example.org/phishing/scam.html") - putting the user name and the logout button in the Larry pane might be a better idea. I still need to figure out the exact UI for this, though.
Assignee: nobody → kaie
Component: Networking: HTTP → Security: UI
QA Contact: networking.http → ui
I'm not thrilled with the idea of putting this in the content area, because it makes phishing for HTTP logins easier.
I agree - I think this is a better fit as part of the site-specific-notifications/doorhanger work - if a site wants you to login, that prompt should come visibly from chrome, not content, to reduce the ability of sites to spoof it. Having said that, I have no objection to it looking much prettier than it currently does.
I wonder if putting the credential fields & login button into Larry (& popping up the Larry panel on 401/407 errors) is a good idea... (the logout button will probably go into Larry anyway).
As a user; Bug 540516 would enhance the overall experience of authentication
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 399583
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.