Switch to using tab-modal prompt dialogs for HTTP authentication

NEW
Unassigned

Status

()

Toolkit
General
P3
normal
8 years ago
18 days ago

People

(Reporter: Ehsan, Unassigned)

Tracking

(Blocks: 10 bugs)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qx:spec], URL)

(Reporter)

Description

8 years ago
With bug 59314 fixed, we should probably port our HTTP authentication dialogs to be tab-modal and not window-modal.

Comment 1

8 years ago
duplicate of bug 377496?
(Reporter)

Comment 2

8 years ago
This bug will solve bug 377496 as well.
Blocks: 377496

Comment 3

8 years ago
And what about bug 567804 "Convert HTTP Auth modal dialog to a doorhanger"?
(Reporter)

Comment 4

8 years ago
They're basically covering the same thing, only with two different UI proposals.  We should decide which path we want to take...
Keywords: uiwanted

Comment 5

8 years ago
Security related dialogs shouldn't be implemented using the tab-modal dialogs (at least in their current form) as they are easily spoofable.
Since as earlier comments mention this has security implications, and is also related to the user's identity, the UX team was planing to use our doorhanger approach over in bug 567804 (also related to the account manager work we have in progress for after Firefox 4:  http://people.mozilla.com/~faaborg/files/firefox4Mockups/accountManager/account%20manager%20i6.png )
I'm not particularly thrilled with putting HTTP Auth prompts entirely into content, due to spoofing. Although that's largely already a lost battle. Sigh.

Anyway, I think doorhangers (or something like them) are probably somewhat better, and Account Manager in general even better still.

So, WONTFIX in favor of bug 567804 instead.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
Duplicate of this bug: 613895

Updated

8 years ago
Duplicate of this bug: 616847
(Reporter)

Updated

7 years ago
Duplicate of this bug: 659323

Updated

6 years ago
Duplicate of this bug: 743555
Duplicate of this bug: 849802

Updated

5 years ago
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(In reply to Justin Dolske [:Dolske] from comment #7)
> I'm not particularly thrilled with putting HTTP Auth prompts entirely into
> content, due to spoofing. Although that's largely already a lost battle.
> Sigh.

Spoofing is not much of an issue as long as we only show the dialog box for the document origin, AFAICT.
Blocks: 411085, 616843, 676434
OS: Mac OS X → All
Hardware: x86 → All

Comment 14

5 years ago
:shorlander and I are not concerned about spoofing here. Spoofing the prompt is neither more dangerous nor more difficult that spoofing any HTML login form on the web. HTTP authentication is inherently modal and should display a modal prompt that can be dismissed easily by accident.

The solution proposed here is better than the one in bug 567804. Firefox for Windows 8 Metro will be implementing a solution similar to this one.
Status: REOPENED → NEW
Keywords: uiwanted

Comment 15

5 years ago
(In reply to Frank Yan (:fryn) from comment #14)
> :shorlander and I are not concerned about spoofing here. Spoofing the prompt
> is neither more dangerous nor more difficult that spoofing any HTML login
> form on the web. HTTP authentication is inherently modal and should display
> a modal prompt that can be dismissed easily by accident.

I get the impression :Dolske is thinking about taking an opportunity to make spoofing more difficult by making the prompt visibly extend outside the content region.

I suppose another option would be to visually differentiate privileged and unprivileged tab-modal dialogs using some other mechanism. (eg. Tinting or patterning a highly-visible portion of the chrome while a privileged tab-modal is being displayed)
(In reply to Frank Yan (:fryn) from comment #14)
> :shorlander and I are not concerned about spoofing here. Spoofing the prompt
> is neither more dangerous nor more difficult that spoofing any HTML login
> form on the web.

Not true. Consider (on page https://victim.example.com/):

    <img src='http://attacker.example.com'>

This can force an HTTP auth prompt for http://attacker.example.com in the UI context of http://victim.example.com, and it is up to the user to notice that he's authenticating for something other than the page by reading the text of the HTTP auth dialog box very carefully, which is an unreasonable expectation for us to make of our users.

However, I agree that, as long as we fix bug 647010, then we don't have to worry about it here. (That's what I was saying in comment 13.) However, if we don't/can't fix bug 647010 then we will need a solution for spoofing. And, we may find that fixing bug 647010 is impossible due to compatibility issues, especially for XHR.

> HTTP authentication is inherently modal and should display
> a modal prompt that can be dismissed easily by accident.

I guess you mean "cannot be dismissed easily by accident." But, I thin it is likely there must be some way to dismiss it on purpose. (The fact that doorhangers can be dismissed accidentally and then become difficult/impossible to resurrect are one of the most serious deficiencies of the doorhanger UX in general.)

I disagree that HTTP authentication inherently requires a modal dialog box. We could always, by default, just display the error page that results when the user refuses to log in and then have the user initiate the login explicitly if he/she chooses. I imagine that we will eventually have to do something similar for SSL client certificate authentication. The advantage of doing things this way is that the error page can give the user instructions regarding which credentials to use amongst other things. However, I agree that a modal prompt is the "safe" choice, assuming there is a way to cancel the dialog box to read the error page. (But, then, you end up again with the problem of "How do I get the HTTP auth dialog box back after I've read the error page?")
(In reply to Brian Smith (:bsmith) from comment #16)
> (In reply to Frank Yan (:fryn) from comment #14)
> > :shorlander and I are not concerned about spoofing here. Spoofing the prompt
> > is neither more dangerous nor more difficult that spoofing any HTML login
> > form on the web.
> 
> Not true. Consider (on page https://victim.example.com/):
> 
>     <img src='http://attacker.example.com'>

Also, consider in particular iframes:

<iframe src='http://attacker.com'>
</iframe>

Especially when the iframe is not even visible, it is easy to confuse the user into entering the embedding page's credentials into the embedded iframe page's HTTP auth dialog box.

Comment 18

5 years ago
(In reply to Brian Smith (:bsmith) from comment #17)
> (In reply to Brian Smith (:bsmith) from comment #16)
> > (In reply to Frank Yan (:fryn) from comment #14)
> > > :shorlander and I are not concerned about spoofing here. Spoofing the prompt
> > > is neither more dangerous nor more difficult that spoofing any HTML login
> > > form on the web.
> > 
> > Not true. Consider (on page https://victim.example.com/):
> > 
> >     <img src='http://attacker.example.com'>
> 
> Also, consider in particular iframes:
> 
> <iframe src='http://attacker.com'>
> </iframe>
> 
> Especially when the iframe is not even visible, it is easy to confuse the
> user into entering the embedding page's credentials into the embedded iframe
> page's HTTP auth dialog box.

Good point.

Does anyone have any ideas for a generally-applicable way to provide better indication of the source of a login prompt now that we're in an era where it's so common for a site to be stitched together with content from multiple domains?

Comment 19

5 years ago
Bug 647010 is about only allowing HTTP auth from the top level document. Does this cover your concerns?

Comment 20

5 years ago
well give the url and the frame name information to user, it's better to check what password browser is asking about when we have many passwords to enter
(In reply to Brian Smith (:bsmith) from comment #16)

> However, I agree that, as long as we fix bug 647010, then we don't have to
> worry about it here. (That's what I was saying in comment 13.) However, if
> we don't/can't fix bug 647010 then we will need a solution for spoofing.
> And, we may find that fixing bug 647010 is impossible due to compatibility
> issues, especially for XHR.

Yeah, this is the crux of the issue. Can we try fixing bug 647010 now, seeing if that sticks, and then go with a tab-modal prompt? It probably needs to stick though an actual release to shake out the full impact of things it might break... Frank, how's that match with Metro's timing? (Or maybe Metro can take a fix for 647010 in the interm, lest legacy compat issues prevent Firefox Desktop from shipping it.)

> (The fact that
> doorhangers can be dismissed accidentally and then become
> difficult/impossible to resurrect are one of the most serious deficiencies
> of the doorhanger UX in general.)

Fodder for another bug, that that's quite intentional.

> I disagree that HTTP authentication inherently requires a modal dialog box.

Well, it does if you're loading resources within the page. The most obvious example being loading a script that triggers authentication... The rest of the page may depend upon effects of the script's execution.

But if 647010 is actually going to only allow the top-level doc itself to trigger authentication, then you're right. The "prompt" can just be an error page with a username+password entry field.

I'm all for 647010, but I fear that it carries a pretty big webcompat risk. And so we either need to tread carefully and try to fix it, or ensure that any auth prompt changes we make here are non-spoofable.

Note that there are 2 subtly different issues:

One is that a cross-origin auth prompt is something many users won't understand (no matter what the UI is), and so we should do things like 647010 to make that problem go away.

The other is that given the web-we-have and not the web-we-want, how do we do our best to give users the info/tools to make the best of a bad situation? (Specifically for users to do understand or have been told what to look for.)
(In reply to Justin Dolske [:Dolske] from comment #21)
> Yeah, this is the crux of the issue. Can we try fixing bug 647010 now,
> seeing if that sticks, and then go with a tab-modal prompt? It probably
> needs to stick though an actual release to shake out the full impact of
> things it might break... Frank, how's that match with Metro's timing? (Or
> maybe Metro can take a fix for 647010 in the interm, lest legacy compat
> issues prevent Firefox Desktop from shipping it.)

I think that we should start working on bug 647010, but I don't think that bug 647010 should block this bug. I just want to make sure that people understand that spoofing *is* still a concern and fixing this bug isn't the last word on improving the HTTP auth experience; i.e. I want to avoid running into the "we just modified the HTTP auth UX once, and it would be too confusing to change it again so soon" type of argument.

> > I disagree that HTTP authentication inherently requires a modal dialog box.
> 
> Well, it does if you're loading resources within the page. The most obvious
> example being loading a script that triggers authentication... The rest of
> the page may depend upon effects of the script's execution.

Right, though I am curious about how much of a problem it would be in practice. It is something we could definitely measure the impact of with telemetry, "relatively easily." If people think it would be valuable to consider a non-modal HTTP auth prompt, either now or in the future, we could investigate it.

> But if 647010 is actually going to only allow the top-level doc itself to
> trigger authentication, then you're right. The "prompt" can just be an error
> page with a username+password entry field.

The motivation for bug 647010 is to prevent some kinds of cross-origin attacks, and we can prevent those types of attacks while still allowing same-origin subresources to trigger the HTTP auth prompt. However, if the UX teams think it would be useful to limit the prompt to only the top-level document, then we could experiment with that as part of bug 647010.

> I'm all for 647010, but I fear that it carries a pretty big webcompat risk.
> And so we either need to tread carefully and try to fix it, or ensure that
> any auth prompt changes we make here are non-spoofable.

I suggest that we assume that we can fix bug 647010 so that we can make forward progress on this bug, and if that assumption turns out to be wrong, then we can consider implementing alternative approaches to subresource-based spoofing later.
Duplicate of this bug: 882604

Comment 24

5 years ago
Please note that having tab-modal prompt, [bug 896253] with
infinite-load-until-the-first-and-only-auth-prompt-proceeded can only be
amplified because it can happen with only a single FF window opened
(as opposed to current situation in which the bug is only exposed with
more windows accessing the same authed site -- quite rare).
No longer blocks: 873810
Duplicate of this bug: 741217
Duplicate of this bug: 879005
Duplicate of this bug: 906442

Updated

4 years ago
Blocks: 950073
Whiteboard: [triage]

Updated

4 years ago
Whiteboard: [triage]

Updated

4 years ago
No longer blocks: 950073
Duplicate of this bug: 951649

Updated

4 years ago
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Whiteboard: [ux] p=0 → [ux] p=3 s=it-30c-29a-28b.2

Updated

4 years ago
Whiteboard: [ux] p=3 s=it-30c-29a-28b.2 → [ux] p=3 s=it-30c-29a-28b.2 [qa+]

Updated

4 years ago
QA Contact: manuela.muntean

Updated

4 years ago
Assignee: philipp → mmaslaney
Carry over to Iteration it-30c-29a-28b.3
Whiteboard: [ux] p=3 s=it-30c-29a-28b.2 [qa+] → [ux] p=3 s=it-30c-29a-28b.3 [qa+]
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago4 years ago
Resolution: --- → FIXED

Comment 31

4 years ago
I don't think this bug is supposed to be marked as fixed, is it? Though, if you want to continue the implementation in Bug 977037, please mark as duplicate.
Flags: needinfo?(mmaslaney)
Flags: needinfo?(mmaslaney)
Resolution: FIXED → DUPLICATE
Duplicate of bug: 977037

Updated

4 years ago
No longer blocks: 950073
Whiteboard: [ux] p=3 s=it-30c-29a-28b.3 [qa+]
(Reporter)

Comment 33

4 years ago
This bug is neither fixed, nor a dupe of bug 977037.  Bug 977037 is just covering the designs, and doesn't focus on the implementation work, which should presumably happen here.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Returning to the Backlog for Gavin, Chad and Madhava to review.
Blocks: 950073
Status: REOPENED → NEW
Whiteboard: p=0

Updated

4 years ago
Depends on: 983796

Updated

4 years ago
Whiteboard: p=0 → p=0, [qa+]

Updated

4 years ago
QA Contact: manuela.muntean → camelia.badau

Updated

4 years ago
No longer blocks: 950073
Flags: firefox-backlog+
Whiteboard: p=0, [qa+] → p=0 [qa+]
Comment hidden (off-topic)

Updated

4 years ago
Summary: Switch to using tab-modal prompt dialogs for HTTP authentication → Breakdown: Switch to using tab-modal prompt dialogs for HTTP authentication
Whiteboard: p=0 [qa+] → p=0 [qa-]

Comment 36

4 years ago
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #0)

> we should probably port our HTTP authentication
> dialogs to be tab-modal and not window-modal

Yes. And the menus have to be operational.

I have a Firefox tab asking me authentication. 
To look up my auth info, I need to go to a webmail. So I press Apple N, to create a new window. 
This does not work. Because the menu bar is crippled. 
So I go to Safari to open the needed webmail. 
This is a failure of Firefox.

This needs to be improved. Thank you.

Updated

4 years ago
Summary: Breakdown: Switch to using tab-modal prompt dialogs for HTTP authentication → Switch to using tab-modal prompt dialogs for HTTP authentication
Whiteboard: p=0 [qa-] → p=0 [qa+]

Updated

4 years ago
Depends on: 1016403

Comment 37

4 years ago
(In reply to Nicolas Barbulesco from comment #36)
> Yes. And the menus have to be operational.
> 
> I have a Firefox tab asking me authentication. 
> To look up my auth info, I need to go to a webmail. So I press Apple N, to
> create a new window. 
> This does not work. Because the menu bar is crippled. 
> So I go to Safari to open the needed webmail. 
> This is a failure of Firefox.
Apologies if this is just a "+1" - but I feel I must echo the above sentiment.

In my case when I open Firefox on either my laptop or desktop, about 10-15 pinned tabs autoload, of which about 7 of these tabs steal focus due to their authentication dialogs.

For me I would prefer to have those tabs higlight (or flash or whatever, as long as it doesn't steal focus) and only ask me for the auth when I actually click on the tab. The present alternative is quickly clicking "Cancel" for each popup and re-loading them later on.

As with Nicolas experience, this is a fail, temporarily making Firefox inconvenient/unusable until I've gone through each of these tabs.

"Steal focus" should be a swearphrase.
Specs can be found in this bug: 977037
Whiteboard: p=0 [qa+] → p=0 [qa+] [qx]

Updated

3 years ago
Severity: enhancement → normal

Updated

3 years ago
Duplicate of this bug: 1123729

Comment 40

3 years ago
FireFox 36.0.4 - problem still here :(
Whiteboard: p=0 [qa+] [qx] → p=0 [qa+] [qx:spec]

Comment 41

3 years ago
FireFox 39.0.3 - problem still here :(

Comment 42

3 years ago
Shutting off authentication from more than one origin point was not a bug fix. It was a breaking of useful functionality.  A strongly-worded embedded warning with the ability to add and store an exception would have been a much better solution instead of just pulling the rug on thousands of sites that rely on this functionality and have for years and years.

Updated

2 years ago
Duplicate of this bug: 1202429
Blocks: 1271852
Blocks: 516781

Updated

2 years ago
See Also: → bug 1312243

Comment 44

11 months ago
It was put to my attention that this bug is actively exploited in the wild to extort ransom from website visitors. The attackers site keeps reloading so that the authentication dialog will immediately pop up again if closed, denying the victim any access to Firefox.
The authentication message reads something like "Your browser has been locked. Call 0800-xxx to regain access."

The only solution is to kill the firefox process with system tools. When firefox is then restarted and set to automatically restore the previous session the dialog will immediately occur again.
Blocks: 1312874
Duplicate of this bug: 1389155
Flags: qe-verify+
Priority: -- → P3
Whiteboard: p=0 [qa+] [qx:spec] → [qx:spec]
Duplicate of this bug: 1373353
Duplicate of this bug: 1418563
See Also: → bug 1412559

Comment 48

5 months ago
Seems to me that this is a serious issue and should be upgraded to P1. I just encountered a page with a fake Firefox error page and a repeated HTTP authentication dialog and I was unable to close the tab to get out of the loop. Anything that lets a page cripple the browser needs to be fixed.
Duplicate of this bug: 1419726

Comment 50

5 months ago
7 years old and still in Quantum? Definitely P1.
Blocks: 1420563
Blocks: 1425264

Updated

4 months ago
See Also: → bug 1427272

Updated

3 months ago
Duplicate of this bug: 1431289

Updated

3 months ago
Duplicate of this bug: 1431730

Updated

3 months ago
Duplicate of this bug: 1431861

Updated

3 months ago
Duplicate of this bug: 1433768
The WebExtensions team is in the initial stages of providing a tab hiding API under bug 1410548. One of the issues we are encountering is that a hidden tab that runs into an HTTP auth request must be forcibly shown to the user, since it is window-modal and would block all interaction with the browser if it were to remain hidden.

While this isn't strictly blocking the implementation of hidden tabs, it definitely destroys the user's workflow. Making HTTP auth tab-modal would present a much nicer user experience when they are using hidden tabs.
Blocks: 1410548

Comment 56

3 months ago
> Switch to using tab-modal prompt dialogs for HTTP authentication

Please: will the switch allow LastPass to regain functionality that was lost in the shift to WebExtensions APIs?

<https://discourse.mozilla.org/t/-/19745/8?u=grahamperrin> relates to LastPass premium support ticket # 6529225 

> … LastPass 4.2.1.21 is not compatible with modal authentication dialogues …

Comment 57

3 months ago
Yep, after upgrade to 58, I see this issue (as many other people),
because Firefox now complete hangs on any page with HTTP auth.

Only way for fix - kill FF process and do not open any page with HTTP authentication..

My case on Mac OS 10.10.5, Fixefox 58.0.1

Comment 58

3 months ago
Alternative workaround that has worked for me:

Put mouse over tab close button (X).
Press escape (ESC) immediately followed by left mouse button (LMB) click.
Depending on speed of the server you may need to try a couple times but I can usually close the tab before it issues another authentication dialog.
Blocks: 1427272

Updated

18 days ago
Duplicate of this bug: 1451161
You need to log in before you can comment on or make changes to this bug.