Closed Bug 1195091 Opened 9 years ago Closed 8 years ago

Basic Authentication does not work under certain circumstances, resulting in an auth error page

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Version:
40 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox40 --- affected
firefox53 - wontfix

People

(Reporter: Thomas.Schroeder, Unassigned)

References

Details

(Keywords: regression, site-compat) 

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150807094952

Steps to reproduce:

Try to login to a page with basic authentication.

Firefox 40.0.2 on a Mac.
Everything was working with the older versions.


Actual results:

I get immediately the error page "authorization required". 


Expected results:

Ask for login.
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Also on Linux with Version 40.0 on Mint
(In reply to Thomas from comment #0)
> Try to login to a page with basic authentication.

Hi reporter, 
unfortunately this report is not very useful because it does not describe the problem well. If you have time and can still reproduce the problem, please read https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines and add a more useful description to this report.
Flags: needinfo?(Thomas.Schroeder)
I don't understand what is not clear?
So here again:
Click on a link to a server that is protected with basic authentication:
http://some.server.com/protected/with/basic/authentication

and instead of getting the popup window where you can enter username and password you get immediately the error page:
Authorization Required

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.

Hope that helps
Thomas
Flags: needinfo?(Thomas.Schroeder)
Component: Untriaged → Security
Product: Firefox → Core
status-firefox40: --- → affected
Keywords: dev-doc-needed, regression, site-compat
OS: Mac OS X → All
Hardware: x86_64 → All
Summary: Basic Authentication does not work → Basic Authentication does not work under certain circumstances, resulting in an auth error page
Thomas, please provide an example real-life URL that doesn't work for you so we can reproduce the problem.  Thanks.
Flags: needinfo?(Thomas.Schroeder)
I am unable to reproduce this bug. My steps are exact as depicted by the user. So like he said (but with real data)

Click on a link to a server that is protected with basic authentication:
- http://www.pagetutor.com/keeper/mystash/secretstuff.html

Expected:

- A dialog box with user name and password field.
- It should accept correct username and password

Actual:

- It does

(username is freddie, password is ss345)
Firefox 40 exhibits this behavior in a framed page that is not hosted on the same server (cross-origin). If you right-click the error page does the context menu show a "This Frame" menu? If so, expand that and View Frame Info to see whether it has a different host name than the outer page.

This same change affects other external resources such as script files and images. See bug 647010.

I think you need to rule out that intentional change to confirm it is a new bug.

Alternately, you could test by temporarily modifying this preference:

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful.

(2) In the search box above the list, type or paste auth and pause while the list is filtered

(3) Double-click the network.auth.allow-subresource-auth preference and edit the 1 to a 2 and click OK

* 1 shows the login dialog only for framed pages, images, etc., hosted on the same site
* 2 allows the login dialog for framed pages, images, etc., hosted on any site

If the page reverts to Firefox 39 behavior after that, it is the new cross-origin block.
@Rabimba: your test to reproduce by opening the URL which triggers basic auth directly is not the problem. That usually works. However, it doesn't work if that URL is loaded by an URL which is used in a page. See bug 1189268 (which this one is possibly a duplicate of), in which I describe two situations which can trigger this bug.
@Jefferson

"Alternately, you could test by temporarily modifying this preference:" That worked! Thank you.

I hope this gets fixed though. Forcing my users to change there browser config is not ideal.
(In reply to Jefferson from comment #7)
> Firefox 40 exhibits this behavior in a framed page that is not hosted on the
> same server (cross-origin). If you right-click the error page does the
> context menu show a "This Frame" menu? If so, expand that and View Frame
> Info to see whether it has a different host name than the outer page.
> 
> This same change affects other external resources such as script files and
> images. See bug 647010.
> 
> I think you need to rule out that intentional change to confirm it is a new
> bug.
> 
> Alternately, you could test by temporarily modifying this preference:
> 
> (1) In a new tab, type or paste about:config in the address bar and press
> Enter/Return. Click the button promising to be careful.
> 
> (2) In the search box above the list, type or paste auth and pause while the
> list is filtered
> 
> (3) Double-click the network.auth.allow-subresource-auth preference and edit
> the 1 to a 2 and click OK
> 
> * 1 shows the login dialog only for framed pages, images, etc., hosted on
> the same site
> * 2 allows the login dialog for framed pages, images, etc., hosted on any
> site
> 
> If the page reverts to Firefox 39 behavior after that, it is the new
> cross-origin block.

Hi,
Yes with changing the value to 2 I got the usual login prompt.
And yes this is a frame and the page is hosted on a different server.
Cheers,
Thomas
Flags: needinfo?(Thomas.Schroeder)
So you guys did this on purpose? lol...

You consider this resolved?: https://bugzilla.mozilla.org/show_bug.cgi?id=647010

Why no user prompt letting the user decide to accept the cross-domain risk?

Come on..
Hi folks,

we have the same problem for our enterprise customers. In the short: webserveriis authenticates the user via Windows-Auth through the iframe. This worked before FF40. In IE this worked and it uses the current NTDOMAIN if setup. Chrome works, but Safari also breaks.

<html>
<head></head>
<body>
    <iframe id="login" src="http://webserveriis"></iframe>  
</body>
</html>

The authenticating server 'webserveriis' and the main server where the html posted above comes from are on different machines and platforms. This can easily be confirmed.

Additionally we have a short JS script which then loads another page when 'login' is loaded (using 'onload'). But this is not relevant here.


Looks like we have to find another solution. May be if the user is prompted for permission for such cases would be okay but surly not perfect in enterprise environments.


Best regards from Germany
https://bugzilla.mozilla.org/show_bug.cgi?id=1197944 fixed this for Firefox 41+.  Not sure if it will be fixed in Firefox 40.  Firefox 41 will be released on September 22nd.  In the meantime, you could use Firefox Beta (which is version 41).
Depends on: 1197944
Hi Tanvi.

In other words the behaviour regarding "WindowsAuth in iframe" will be reverted to FF39-?
(In reply to Ulrich Müller from comment #14)
> Hi Tanvi.
> 
> In other words the behaviour regarding "WindowsAuth in iframe" will be
> reverted to FF39-?

Probably, but I can't say for sure without looking more closely.  You can test this locally by opening a new tab in Firefox and entering about:config.  Go through the dialog to promise you will be careful.  Search for the pref "network.auth.allow-subresource-auth".  If the value is 1, set it to 2.  Then try your use case.  The fix to Firefox 41+ does just this and sets this value to 2.  You can do this in Firefox 40 to see that it works for you.
Hi. With the newly released FF41 the "problem" was solved. Thx!
Based on comment 16 I will close this as Worksforme. If anyone can still reproduce the issue on a current build, please reopen the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Issue still occurring. I cannot paste the URL due to restrictions and I have tried the troubleshooting steps provided here. Could this have anything to do with our SSO system even though it works on Chrome and IE?
(In reply to Madalina from comment #18)
> Issue still occurring. I cannot paste the URL due to restrictions and I have
> tried the troubleshooting steps provided here. Could this have anything to
> do with our SSO system even though it works on Chrome and IE?

Is the problem identical to the description in comment 0 in this bug?

If you trust me enough, you can send the link directly to my bugzilla email, so I can take a look.  However, seeing a reference to SSO suggests I won't be able to reproduce easily.

A minimal test case would be great to have.  Can one be established and published (or sent to me)?
Flags: needinfo?(elefantii)
Is the site actually using HTTP auth, or is it NTLM based?
(In reply to Justin Dolske [:Dolske] from comment #20)
> Is the site actually using HTTP auth, or is it NTLM based?

NTLM
Flags: needinfo?(elefantii)
This bug is back in version 53.0 on osx 10.12.2 

http://www.pagetutor.com/keeper/mystash/secretstuff.html   still is an example of the failure:  

When I load the above URL it says: 

"Authorization Required
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. "

But never prompts for a username password
Mark, isn't bug 1361374 already dealing with this?  You don't have to comment on closed bugs to get more attention.
I commented on this bug first, and then learned from the triage owner I should open a new bug instead.
(In reply to Mark Engelhardt from comment #24)
> I commented on this bug first, and then learned from the triage owner I
> should open a new bug instead.

Yep, I read emails non-linearly and didn't check the date ;)
You need to log in before you can comment on or make changes to this bug.