Bug 41217 – CORS XMLHttpRequest should log a detailed reason for failure when a security check fails

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Web Inspector (Deprecated)

[Stuart Ng]

Steps:

1) Test Page with both IFRAME and XHR Request
2) From the IFRAME, log into the secure page with credentials (This will pop up dialog box asking for credentials)
3) Trigger XHR to be sent to the same secure page. WithCredentials Flag is true

Packet Sequence:

- HTTP GET to secure page

-HTTP Response with 401, and the following headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Credentials: True
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 10

- HTTP GET to secure Page, using basic Authorization and the correct username/password used in step 2 for IFRAME log in
- HTTP Response from Server with 200 (Log in success).

Yet, I am getting a XMLHttpRequest Network Error 101 at the Javascript level. Status = 0 and responseText = ''.

I can reproduce this on both Chrome and Safari.

[Stuart Ng]

Just reproduced in both Sync and Async Request.

Sync mode produces the 101 Error
Async Mode the state just jumps right to 4 and returns blank responseText and status  is 0

[Alexey Proskuryakov]

Does this work in Firefox?

> -HTTP Response with 401, and the following headers:

Does the actual response have all the same headers, or only 401 does?

Can you attach a packet trace, and the source of your client-side test?

> Access-Control-Allow-Credentials: True

Oh, and one more thing. We only support all-lowercase "true" here. I haven't checked the spec, maybe it's a bug.

[Stuart Ng]

Created attachment 59787 [details]
Packet Trace

[Stuart Ng]

All responses have the same headers.
I have updated the server to return all lower case "true" and still same result.

[Alexey Proskuryakov]

> Oh, and one more thing. We only support all-lowercase "true" here. I haven't checked the spec, maybe it's a bug.

That's correct behavior FWIW, CORS requires a case sensitive match for "true".

> and the source of your client-side test

Can you attach that?

[Stuart Ng]

Created attachment 59896 [details]
Client Side Test Page

[Stuart Ng]

Client Side Test Pages Attach. Just replace with your own host name.

[Alexey Proskuryakov]

This is correct behavior, wildcard origin is not allowed if withCredentials is true:

<http://dev.w3.org/2006/waf/access-control/>, section 6.2:

-------------------------------
The resource sharing check algorithm for a given resource is as follows:

If the response includes zero or more than one Access-Control-Allow-Origin header values return fail and terminate this algorithm.

If the Access-Control-Allow-Origin header value is the literal "*" character and the credentials flag is false return pass and terminate this algorithm.

If the value of Access-Control-Allow-Origin is not a case-sensitive match for the value of the Origin header as defined by its specification return fail and terminate this algorithm.

If the credentials flag is true and the response includes zero or more than one Access-Control-Allow-Credentials header values return fail and terminate this algorithm.

If the credentials flag is true and the Access-Control-Allow-Credentials header value is not a case-sensitive match for "true" return fail and terminate this algorithm.

Return pass.
-------------------------------

Let's use this bug to track improved Web Inspector error logging.

[Stuart Ng]

Thanks Alexey. I can get my tests to work.

However, it seems on Safari whenever I sent Asynchronous Request with withCredentials=false it never works. (i.e. I get status = 0 and empty responseText).

On Chrome everything is working as expected.

[Alexey Proskuryakov]

> However, it seems on Safari

Please file a new bug for that (again, attaching a packet trace and your test case).

[Alexey Proskuryakov]

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