Bug 41217 - CORS XMLHttpRequest should log a detailed reason for failure when a security check fails
Summary: CORS XMLHttpRequest should log a detailed reason for failure when a security ...
Status: RESOLVED DUPLICATE of bug 41156
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-25 10:22 PDT by Stuart Ng
Modified: 2010-07-02 17:29 PDT (History)
1 user (show)

See Also:


Attachments
Packet Trace (2.89 KB, application/octet-stream)
2010-06-25 12:21 PDT, Stuart Ng
no flags Details
Client Side Test Page (2.03 KB, text/html)
2010-06-28 05:54 PDT, Stuart Ng
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Ng 2010-06-25 10:22:06 PDT
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.
Comment 1 Stuart Ng 2010-06-25 10:31:08 PDT
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
Comment 2 Alexey Proskuryakov 2010-06-25 12:15:07 PDT
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.
Comment 3 Stuart Ng 2010-06-25 12:21:16 PDT
Created attachment 59787 [details]
Packet Trace
Comment 4 Stuart Ng 2010-06-25 12:21:50 PDT
All responses have the same headers.
I have updated the server to return all lower case "true" and still same result.
Comment 5 Alexey Proskuryakov 2010-06-25 13:12:44 PDT
> 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?
Comment 6 Stuart Ng 2010-06-28 05:54:53 PDT
Created attachment 59896 [details]
Client Side Test Page
Comment 7 Stuart Ng 2010-06-28 05:55:10 PDT
Client Side Test Pages Attach. Just replace with your own host name.
Comment 8 Alexey Proskuryakov 2010-07-01 13:47:24 PDT
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.
Comment 9 Stuart Ng 2010-07-02 06:10:31 PDT
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.
Comment 10 Alexey Proskuryakov 2010-07-02 08:39:29 PDT
> However, it seems on Safari

Please file a new bug for that (again, attaching a packet trace and your test case).
Comment 11 Alexey Proskuryakov 2010-07-02 17:29:08 PDT

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