Solving CORS configuration issues

Unity Engine
,
1

When communicating with the output WebGL

(index):1 Access to XMLHttpRequest at ‘https://api.hoge.info/v1/top’ from origin ‘http://www.hoge.co.jp’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

And an error has occurred.
However, when I confirmed it with the following command

$ curl -vvv --location --request OPTIONS ‘https://api.hoge.info/v1/top’ --header ‘Origin: http://www.hoge.co.jp’ --header ‘access-control-request-method: GET’

< HTTP/2 200
< date: Tue, 27 Oct 2020 04:24:02 GMT
< content-type: text/html; charset=UTF-8
< server: nginx/1.14.1
< x-powered-by: PHP/7.1.25
< cache-control: no-cache, private
< access-control-allow-credentials: true
< access-control-allow-origin: http://www.hoge.co.jp
< access-control-allow-methods: GET
< access-control-allow-headers: Content-Type, X-Requested-With

There was such a response.

Communication processing in the app

UnityWebRequest request = UnityWebRequest.Get( https://api.hoge.info/v1/top );
yield return request.Send();

It is described like this.
Is it because “access-control-request-method: GET” is not attached to the header?
Isn’t this something that is automatically attached when communicating with a browser?

How can I be able to communicate?

I look forward to working with you.

2

As you can see from the error message
access-control-allow-origin: http://www.hoge.co.jp
The access source is restricted to http://www.hoge.co.jp as shown in.
If the address of the Unity WebGL app is http: // localhost: xxxx, it will be blocked.

There are two possible methods

  1. Ask the API provider to add your Unity WebGL app domain, or
    Have the restrictions lifted (access-control-allow-origin: *)
    This request will be rejected because it may be restricted for some reason.

  2. Deploy the Unity WebGL app under http://www.hoge.co.jp
    If you deploy the Unity WebGL app under http://www.hoge.co.jp, the access source of the deployed app will be http://www.hoge.co.jp, so you will be able to access the API.

3

Instead of using a command line curl call to try to reproduce the same conditions after the fact, try looking at the exact OPTIONS request that goes out, by using the browser Network tab. That should show what the actual communication was that occurred. Sometimes browser diagnostics messages about CORS requirements have not been 100% accurate, so seeing the actual communications that took place can help rule out conditions.

1 Like
4

When I checked the Status of the Network tab, it was “(failed) net :: ERR_FAILED”
There was a notation, but no other error notation was found.

Which part of the Network tab should I look at?

5

Even if you use the Chrome extension “CORS Uninstall”

Access to XMLHttpRequest at’https://api.hoge.info/v1/top’ from origin’http://www.hoge.co.jp’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: It does not have HTTP ok status.

Error occurs and communication is not possible.
When you check with the Curl command, you have confirmed that the communication is successful.

Since it is communication using UnityWebRequest, we recognize that it is possible to communicate with WebGL.
Is the cause on the application side?
Do you know any other cause?

6

Does it match the domain part of the WebGL app’s URL and the access-control-allow-origin value in the response header?

7

I’m sorry for being ignorant

Where in the browser can I see the value of “access-control-allow-origin” in response?

8

Displayed after running curl
access-control-allow-origin: http://www.hoge.co.jp
It is “http://www.hoge.co.jp”.

9

Click on the Request, and take a look at the Headers tab for Request Headers and Response Headers.

10

I use this to avoid CORS issue for PHP scripts:

header("Access-Control-Allow-Origin: *");

I use this .htaccess to avoid CORS issue with Addressables:

<IfModule mod_headers.c>
  Header set Access-Control-Allow-Origin "*"
</IfModule>
2 Likes
11

After checking, the following response was displayed.

General
Request URL: https://api.hoge.info/v1/top
Request Method: OPTIONS
Status Code: 403
Remote Address: xxx.xxx.xxx.xxx:xxx
Referrer Policy: strict-origin-when-cross-origin

Response Headers
cache-control: no-cache, private
content-type: text/html; charset=UTF-8
date: Sat, 31 Oct 2020 07:31:52 GMT
server: nginx/1.14.1
status: 403
x-powered-by: PHP/7.1.25

Request Headers
:authority: api.escore.info
:method: OPTIONS
:path: /v1/top
:scheme: https
accept: /
accept-encoding: gzip, deflate, br
accept-language: ja,en-US;q=0.9,en;q=0.8
access-control-request-headers: access-control-allow-credentials,access-control-allow-headers,access-control-allow-methods,access-control-allow-origin
access-control-request-method: GET
origin: http://www.hoge.co.jp
referer: http://www.hoge.co.jp/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

The error display on the console is as follows.
(index):1 Access to XMLHttpRequest at ‘https://api.hoge.info/v1/top’ from origin ‘http://www.hoge.co.jp’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

The file output as WebGL is uploaded to “http://www.hoge.co.jp/hobeBrowser” and started from there.

I know there is an authentication error, but I don’t know where the cause is.

12

The first issue is that the server replies with a HTTP Status of 403 (Forbidden) to the OPTIONS header. Refer to Nginx documentation on how to change the server to not forbid OPTIONS requests. E.g. enable cross-origin resource sharing might help?

However then looking at the HTTP Request, it has the following:

access-control-request-headers: access-control-allow-credentials,access-control-allow-headers,access-control-allow-methods,access-control-allow-origin

That, uh…, looks like garbage. Why is the web page requesting the server for a permission to specify HTTP Response Headers as part of a HTTP Request?

Are you manually adding in HTTP Response headers “access-control-allow-credentials,access-control-allow-headers,access-control-allow-methods,access-control-allow-origin” to the HTTP Request somewhere? If so, remove those headers from the HTTP Request - they are not HTTP Request headers and should not be there. If you are not doing that, then we should figure out who/what is. That looks very incorrect code.

Also, I do not see any “real” HTTP Request headers in that access-control-request-headers list, which suggests that maybe you are not even intending to do a preflighted CORS request in the first place, so the OPTIONS request should not even be need to be sent here?

13

Requests from http to https are blocked even if the value of access-control-allow-origin matches the origin of the WebGL app.

14

Thank you very much.
After correcting the pointed out part, I confirmed that communication was possible.

However, when performing OAuth2 communication for login

I received the response, and the following error was displayed on the console.

The added header will be the one set at the time of the smartphone terminal.
Is it necessary to set up a dedicated CORS communication for OAuth2 communication as well?

I’m sorry to trouble you, but it would be very helpful if you could borrow your wisdom.

I look forward to working with you.

15

OAuth2 authentication is successful, but I think the redirect URL is set incorrectly.

16

In this log, the issue is that the HTTP OPTIONS request came back with

Request URL: https://api.hoge.info/v1/oauth2/token
Request Method: OPTIONS
Status Code: 403
Remote Address: xxx.xxx.xxx.xxx:xxx
Referrer Policy: strict-origin-when-cross-origin

Response Headers
cache-control: no-cache, private
content-type: text/html; charset=UTF-8
date: Sun, 01 Nov 2020 03:17:29 GMT
server: nginx/1.14.1
status: 403
x-powered-by: PHP/7.1.25

That is, the server api.hoge.info is configured to disallow cross-origin HTTP POST requests with the header set “authorization,content-type,x-hoge-env,x-hoge-terminal-id,x-requested-with”.

To be correct, the server api.hoge.info should be configured to instead return something like follows:

Request URL: https://api.hoge.info/v1/oauth2/token
Request Method: OPTIONS
Status Code: 204 No Content
Remote Address: xxx.xxx.xxx.xxx:xxx
Referrer Policy: strict-origin-when-cross-origin

Response Headers
cache-control: no-cache, private
content-type: text/html; charset=UTF-8
date: Sun, 01 Nov 2020 03:17:29 GMT
server: nginx/1.14.1
status: 204 No Content
x-powered-by: PHP/7.1.25
Access-Control-Allow-Origin: https://www.hoge.co.jp
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: authorization,content-type,x-hoge-env,x-hoge-terminal-id,x-requested-with
Access-Control-Max-Age: 86400

See OPTIONS - HTTP | MDN for Preflighted requests in CORS.

In order for how to achieve that with Nginx, see enable cross-origin resource sharing

17

I see a lot of changing headers. Where am I supposed to do this at? Inside of by google bucket I have it done, is there supposed to be another place I need to change headers? A specific script in Unity possibly?6978143--823118--upload_2021-3-26_11-51-0.png

18

I don’t have experience with Google Bucket, but if you haven’t read through these already:
https://cloud.google.com/storage/docs/configuring-cors
https://cloud.google.com/storage/docs/cross-origin
I use UnityWebRequest.Post with PHP and that has worked as a cross-platform solution (WebGL, Win64 and Android so far), aside from also needing the .htaccess for Addressables …in particular to support WebGL being hosted on one server with bundles loaded from another via remote catalog. There was nothing special that had to be done in C# or JS, the CORS errors I’ve dealt with all ended up being server-side issues.
If you’re asking where specifically in a PHP file, just at the top of any you want to communicate with:

<?php
  header("Access-Control-Allow-Origin: *");
?>

The second image you’ve posted mentions several other headers, which would be added in the same way. Personally I’ve only needed Access-Control-Allow-Origin to get things working… which is with web hosting+SSL certificate due to other requirements I have that pretty much rule out any free alternatives (i.e. databases, FFMPEG, etc.). I haven’t dug into this aspect of deployment/CORS beyond that / can’t think of anything else to mention or suggest.

2 Likes