1691824 - odb.org doesn't load due to CORS error

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Ksenia Berezina [:ksenia]]

We've got a report in https://github.com/webcompat/web-bugs/issues/66793 where a site doesn't load due to a CORS error

Steps to reproduce:

1. Visit https://odb.org/ and observe the site

Expected:
Site loads

Actual:
Site doesn't load and only one image is displayed

From morzregression:

12:47.88 INFO: No more integration revisions, bisection finished.
12:47.88 INFO: Last good revision: 23edb23d1885df32c11abdc55b35a66232fc2dc2
12:47.88 INFO: First bad revision: 4ffa919d35f99eb2120e255da5a6d35b7672e26b
12:47.88 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=23edb23d1885df32c11abdc55b35a66232fc2dc2&tochange=4ffa919d35f99eb2120e255da5a6d35b7672e26b

I don't have an access to https://bugzilla.mozilla.org/show_bug.cgi?id=1687364, but I suppose this is caused by the fact that the site is making a preflight request to https://crouton.odb.org/site-config , with authorization in Access-Control-Request-Headers but has a wildcard in response (access-control-allow-headers: *)

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://crouton.odb.org/site-config. (Reason: header ‘authorization’ is not allowed according to header ‘Access-Control-Allow-Headers’ from CORS preflight response).

Comment 1

[Ksenia Berezina [:ksenia]]

Hi Kershaw, wonder if you could confirm that this is a website issue and to fix this they would need to add authorization to Access-Control-Allow-Headers to make the preflight request work? (I can try to contact them if that is the case)

Comment 2

[Kershaw Chang [:kershaw]]

(In reply to Ksenia Berezina [:ksenia] from comment #1)

Hi Kershaw, wonder if you could confirm that this is a website issue and to fix this they would need to add authorization to Access-Control-Allow-Headers to make the preflight request work? (I can try to contact them if that is the case)

Yes, this is the correct solution. According to mdn, they need to add authorization to Access-Control-Allow-Headers explicitly.

Comment 3

[Ksenia Berezina [:ksenia]]

Thanks for looking into it. I'll close this bug in favor of the github issue

Comment 4

[Anne (:annevk)]

Do we know why this website works in Chrome (and Safari?)? If they don't require Authorization to be explicitly listed, perhaps we should revert bug 1687364 for now and have a standards discussion first.

Comment 5

[Kershaw Chang [:kershaw]]

(In reply to Anne (:annevk) from comment #4)

Do we know why this website works in Chrome (and Safari?)? If they don't require Authorization to be explicitly listed, perhaps we should revert bug 1687364 for now and have a standards discussion first.

I can confirm that Chrome doesn't require Authorization to be explicitly listed.
Anne, should we revert bug 1687364 now?

Comment 6

[Anne (:annevk)]

I have updated that bug with more information.

Comment 7

[Anne (:annevk)]

Resolving this as WORKSFORME for now given that we backed out the change. It might still be worth it to contact the site, but we'll only change behavior here if all browsers decide to change.

Comment 8

[Ksenia Berezina [:ksenia]]

Ok, thanks for the update!