CORS Barrier from subdomain - .htaccess

Question

I use my Web application in a subdomain also, I use a different subdomain for the interface objects.
That's the problem: CORS
Fonts are not installed because of cors barrier.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at
https://assets.example.com/fonts/simple-line-iconsc05f.ttf?thkwh4.
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Application:
https://ap.example.com
Assets:
https://assets.example.com
I added the root of Web application, .htaccess file:
<FilesMatch "\.(ttf|otf|eot|woff|svg|woff2)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
Also, nginx.conf file:
server {
...
location ~* \.(eot|ttf|woff|woff2)$ {
add_header 'Access-Control-Allow-Origin' '*';
}
...
}
Nevertheless, I'm still stuck in the cors barrier.
It has been tried many times with cache and different browsers. The result has not changed.

Answer 1

You can try this:
location / {
if ($request_filename ~* ^.*?/([^/]*?)$) {
set $filename $1;
}
if ($filename ~* ^.*?\.(eot)|(ttf)|(woff)|(jpg)|(png)|(css)|(js)$){
add_header 'Access-Control-Allow-Origin' "*";
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Headers' 'User-Agent,Keep-Alive,Content-Type,X-Api-Token';
}
}

Answer 2

#Editor, whilst the solution from #Sahipsiz might work, CORS is a complex topic, and as per my previous comment, that solution is technically incorrect (even though it may have solved your symptom, the underlying problem is still there)...
First off, if your browser decides that CORS is in play, it will send the Origin request header, containing the full domain of the requesting page, e.g.:
Origin: https://ap.example.com
If the request doesn't include the Origin request header, then this isn't a CORS request, and you don't need to do anything CORS-related.
If you are sure that you don't need support for cookies to be passed to/from the assets domain, you can simply respond to a CORS request by including this response header:
Access-Control-Allow-Origin: *
However, if you do need cookie support, you'll need to include these two response headers:
Access-Control-Allow-Origin: <value of Origin request header>
Access-Control-Allow-Credentials: true
So in your case, you would respond with this:
Access-Control-Allow-Origin: https://ap.example.com
Access-Control-Allow-Credentials: true
In some cases (which may well not apply to you, since you're just retrieving fonts), prior to making the main GET/POST/PUT/DELETE request, your browser will first make an additional 'preflight' OPTIONS request - this is basically the browser asking permission to make the main request. The OPTIONS request includes a number of CORS-specific request headers, and you need to return some 'matching' CORS response headers to this OPTIONS request (but no response body). If you do this correctly, the browser will then make the main request.
For that OPTIONS request, you should return the following CORS response headers:
Access-Control-Allow-Origin: <value of Origin request header>
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: <value of Access-Control-Request-Method request header>
Access-Control-Allow-Headers: <value of Access-Control-Request-Headers request header>
Those response headers tell the browser that you are OK with the GET/POST/DELETE/PUT request it's about to make.
You can optionally also pass the following response header to the OPTIONS request (in addition to the four defined above):
Access-Control-Max-Age: 86400
which tells the browser to cache the OPTIONS response headers - this stops it from making the preflight request every time.
CORS ain't easy.