399583 - HTTP Authentication should happen in content area, not in a modal dialog

Status: RESOLVED DUPLICATE of bug 567804

(Core Graveyard :: Security: UI, enhancement)

Description

[Scott Robinson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6

The HTTP password authentication dialog is modal. It should be the same kind of alert that occurs for blocked popups.

Mozilla could take a leading role here - the horrible UI behind HTTP authentication is one of the reasons why authentication is done using HTML forms.

Adding this and thereby allowing websites to take advantage of it will cause users to become used to entering passwords in the browser as opposed to the page.

Furthermore, this will open up alternate authentication schemes in the same UI. (think SRP or something)

Reproducible: Always

Steps to Reproduce:
1. Surf to a website using HTTP basic or digest authentication.

Actual Results:  
Wince in pain at the modal dialog.

Expected Results:  
A non-modal popup for that tab only.

Comment 1

[Jo Hermans]

For that tab only ? Bug 123913

Comment 3

[Jesse Ruderman]

Not really a dup of bug 123913, IMO.  Fixing that would be one possible solution, but I think it would be better to make the http auth UI a replacement page (similar to error pages) instead of a modal dialog.

Comment 4

[nalyman]

I think Jesse is right. HTTP authentication should not open a modal dialog. When restoring a session with multiple tabs and one tab needs HTTP authentication, then the rendering of every other tab is blocked. A custom HTML or XUL ui similar to error pages - as suggested by Jesse - would be a good idea. There's also a need for a way to log out from such a session to prevent random guy sitting in front of the browser stealing information - why has one to exit Firefox to forget the password?

(In reply to comment #3)

> Not really a dup of bug 123913, IMO.  Fixing that would be one possible
> solution, but I think it would be better to make the http auth UI a replacement
> page (similar to error pages) instead of a modal dialog.

Comment 5

[Jesse Ruderman]

You can log out using Tools - Clear Recent History - Active Logins.  Not the most discoverable, but possible :)  If we used a page instead of a dialog for logging in, it would be more natural to include instructions for logging out.

Comment 6

[Jesse Ruderman]

Attachment: screenshot of current HTTP Auth dialog

This isn't just an annoyance; it's a security problem.

* The dialog is pretty much indistinguishable from an in-page spoof.

* I'm blocked from seeing the URL bar (and it shows the previous page's URL).

* I'm blocked from accessing Larry.

* The only site-identity information I have is a non-human-parsable URL inside a sentence inside a paragraph.  And sites get to add text to that paragraph!

Comment 7

[Jesse Ruderman]

Keeping the "dialog" appearance while making it actually be non-modal wouldn't really help, because users wouldn't know it's non-modal.  So I'm morphing this bug slightly to be about changing it to an in-page thing.

(Interestingly enough, Fennec is already going in this direction: bug 486693.)

Comment 8

[Nickolay_Ponomarev]

There's more discussion on this in bug 244273, and bug 411085 "overhaul HTTP authentication prompting" appears closely related to this one, setting dependency accordingly.

Comment 9

[Justin Dolske [:Dolske]]

Doesn't moving this to the content area make the "indistinguishable from an in-page spoof" problem even worse?

Comment 10

[Jesse Ruderman]

No, why would a page spoof its own authentication dialog?  If we want to indicate that the authentication is hash-protected from certain MITM attacks, we can reflect analogously to how we indicate https.

Comment 11

[Justin Dolske [:Dolske]]

No, the problem is ending up on an evil site, which present a page that looks identical to the browser's content-area promp for some other site.

Comment 12

[Jesse Ruderman]

I think users have a better shot at parsing the host/domain out of the address bar than they do out of a sentence.  Especially once we fix the address bar to highlight the domain.

Comment 13

[Kai Engert (:KaiE:)]

Adding Johnath as this touches security UI.

Not sure about the right component, all unencrypted http auth prompts are handled by Mozilla's networking protocol code, while Security:UI component was usually used for protocol independent SSL UI.

Comment 16

[Rimas Kudelis [use needinfo to ping]]

Attachment: Authentication required UI mockup

Attaching a mockup of what such login page could look like.

Note the Remember password checkbox is not necessary in it, because we could still display the top panel after the form has been submitted. It actually even makes more sense to do it then, because at that point the user knows for sure if the supplied credentials work or not.

Similarly, if a fallback page link is present and the user clicks it, a similar top bar could be presented when showing it, which would allow the user to get the login form back if the 401 page is not what they wanted to see. :)

Comment 17

[Jesse Ruderman]

I'd rather not show the hostname in the content area.  We want users to get used to looking at the address bar (and Larry), because anything in the content area can be spoofed.

Likewise, we don't need to say "the site introduced itself as" and "if you trust this website".

Comment 18

[Rimas Kudelis [use needinfo to ping]]

(In reply to comment #17)
> I'd rather not show the hostname in the content area.  We want users to get
> used to looking at the address bar (and Larry), because anything in the content
> area can be spoofed.

I don't mind that. Though I took the idea from the untrusted certificate prompt page.

> Likewise, we don't need to say "the site introduced itself as" and "if you
> trust this website".

Don't mind that either.

Regarding "the site introduced itself as" – I took bug 244273 comment #19 and #21 into account. I absolutely agree that the text could be refined in all labels. After all, my attachment is just a ten-minute mockup. I just want see this bug moving towards RESOLVED FIXED status. :)

Comment 19

[Rimas Kudelis [use needinfo to ping]]

Looking at the attachments of bug 244273, it looks like we currently have "The site says:". I just improvised a little.

Comment 20

[Rimas Kudelis [use needinfo to ping]]

So, what does this bug need to be solved?

Comment 21

[Kai Engert (:KaiE:)]

(In reply to comment #20)
> So, what does this bug need to be solved?

Someone who does the work.

Comment 22

[Sk]

Since JS alerts are now tab-modal and do not block interacting with other tabs, maybe it's time to make Basic authentication behave the same way? In Opera it's already done, so maybe somebody in charge could put parity-opera flag.

And would be good to work it out, cause now it looks like an anachronism.

Comment 24

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Duping to bug 567804. If you think a doorhanger isn't the right UI then discuss it in that bug.