Last Comment Bug 521588 - Redesign HTTP 401/407 authentication to use a login page (similar to the 404 "friendly error page")
: Redesign HTTP 401/407 authentication to use a login page (similar to the 404 ...
Status: VERIFIED DUPLICATE of bug 399583
Product: Core Graveyard
Classification: Graveyard
Component: Security: UI (show other bugs)
: unspecified
: All All
-- enhancement with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
Blocks: 260839 61681
  Show dependency treegraph
Reported: 2009-10-10 12:45 PDT by Gábor Stefanik
Modified: 2016-09-27 13:03 PDT (History)
10 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

Mockup of the login page to show. (21.86 KB, image/png)
2009-10-10 12:45 PDT, Gábor Stefanik
netrolller.3d: ui‑review?

Description User image Gábor Stefanik 2009-10-10 12:45:07 PDT
Created attachment 405691 [details]
Mockup of the login page to show.

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 "", 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 ""-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").
-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://". 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.
Comment 1 User image Gábor Stefanik 2009-10-11 07:42:34 PDT
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 "") - 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.
Comment 2 User image Justin Dolske [:Dolske] 2009-10-12 19:23:02 PDT
I'm not thrilled with the idea of putting this in the content area, because it makes phishing for HTTP logins easier.
Comment 3 User image Johnathan Nightingale [:johnath] 2009-10-13 08:05:43 PDT
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.
Comment 4 User image Gábor Stefanik 2009-10-13 11:50:35 PDT
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).
Comment 5 User image Daniel O'Connor 2010-01-18 18:36:49 PST
As a user; Bug 540516 would enhance the overall experience of authentication
Comment 6 User image Gábor Stefanik 2011-01-28 11:15:27 PST

*** This bug has been marked as a duplicate of bug 399583 ***

Note You need to log in before you can comment on or make changes to this bug.