We Keep Coding

CORS errors in react application

I'm using webdav library inside a react application. As of now, I'm in an early stage of development and I'm just logging the results of a call that should list the contents of a directory. To do that I just created a method that instantiates the client and makes an ls of the directories and then logs them in the console.
const getItems = async() => {
const client = createClient(
"https://mywebdavurl.com/",
{
authType: AuthType.Password,
username: "user",
password: "passwd",
headers: {
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Methods": "DELETE, POST, GET, OPTIONS",
"Access-Control-Allow-Headers": "Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"
}
}
);
console.log(client)
const directoryItems = await client.getDirectoryContents("/");
console.log(directoryItems);
}
function App() {
getItems()
return (
<Router>
<Header />
<Switch>
<Route exact path={ROUTES.HOME}>
Hello Sputnik
</Route>
</Switch>
</Router>
);
}
When I open the app on the browser (localhost) using Chrome, I receive some strange errors that I can't fix.
Network tab in the inspector
First of all, I can't fix the CORS problem. I tried adding the headers but the result will not change and I will receive this error in my console:
Access to XMLHttpRequest at 'https://mywebdavurl.com/' from origin 'http://localhost:3001' 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.
I tried, just for debugging purposes to use a Chrome Extension that disables the CORS. If I use this, the error is quite different and says:
Access to XMLHttpRequest at 'https://mywebdavurl.com/' from origin 'http://localhost:3001' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.
Well, if you look at the image, you can see that I have both a CORS problem and an Unauthorized problem. If I check my WebDAV server logs they state this:
2021/10/21 13:44:03 [error] 12#0: *106 no user/password was provided for basic authentication, client: 100.70.4.1, server: , request: "OPTIONS / HTTP/1.1", host: "https://mywebdavurl.com/", referrer: "http://localhost:3001/ "
2021/10/21 13:44:14 [error] 12#0: *106 no user/password was provided for basic authentication, client: 100.70.4.1, server: , request: "OPTIONS / HTTP/1.1", host: "https://mywebdavurl.com/", referrer: "http://localhost:3001/ "
2021/10/21 13:44:14 [error] 12#0: *105 no user/password was provided for basic authentication, client: 100.64.6.1, server: , request: "OPTIONS / HTTP/1.1", host: "https://mywebdavurl.com/", referrer: "http://localhost:3001/ "
2021/10/21 13:49:20 [error] 12#0: *109 no user/password was provided for basic authentication, client: 100.70.6.1, server: , request: "OPTIONS /results/ HTTP/1.1", host: "https://mywebdavurl.com/", referrer: "http://localhost:3001/ "
2021/10/21 13:49:20 [error] 12#0: *110 no user/password was provided for basic authentication, client: 100.64.8.1, server: , request: "OPTIONS /results/ HTTP/1.1", host: "https://mywebdavurl.com/", referrer: "http://localhost:3001/ "
If I check the contents of the request and responses from the network tab in the inspector, I get the following:
Requests with type XHR and status CORS error
Referrer Policy: strict-origin-when-cross-origin
Provisional headers are shown
Learn more
Accept: text/plain
Access-Control-Allow-Headers: Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With
Access-Control-Allow-Methods: DELETE, POST, GET, OPTIONS
Access-Control-Allow-Origin: *
Authorization: Basic dXNlcjpwYXNzd2Q=
Depth: 1
Referer: http://localhost:3001/
sec-ch-ua: "Google Chrome";v="95", "Chromium";v="95", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36
Requests with type Preflight and status 401
Request Method: OPTIONS
Status Code: 401 Unauthorized
Remote Address: 10.107.50.24:443
Referrer Policy: strict-origin-when-cross-origin
access-control-allow-headers: *
access-control-allow-methods: GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: *
access-control-expose-headers: *
Connection: close
Content-Length: 605
Content-Type: text/html; charset=utf-8
Date: Thu, 21 Oct 2021 11:44:14 GMT
Server: nginx/1.4.6 (Ubuntu)
Set-Cookie: d8522de4f35024212f5d0e7f0b289d29=3570640034998b52c04921bcd836972d; path=/; HttpOnly; Secure; SameSite=None
WWW-Authenticate: Basic realm="Restricted"
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en,de-DE;q=0.9,de;q=0.8,en-US;q=0.7
Access-Control-Request-Headers: access-control-allow-headers,access-control-allow-methods,access-control-allow-origin,authorization,depth
Access-Control-Request-Method: PROPFIND
Connection: keep-alive
Host: https://mywebdavurl.com/
Origin: http://localhost:3001
Referer: http://localhost:3001/
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/95.0.4638.54 Safari/537.36
From what I can see, the XHR requests have the CORS headers and the Authorization header. Yet I receive the CORS error. The preflight request, instead, is not filled with those headers.
In the end, I tried one last thing that gave me, once again an unexpected result: I open Chrome using the following command-line flags:
C:\Users\Francesco\AppData\Local\Google\Chrome\Application\chrome.exe --disable-web-security --disable-gpu --user-data-dir=~/chromeTemp
When I do that, everything works fine. Of course, the codebase is the same. In this case, I have in the network tab in Chrome just two entries (same values, maybe I'm doing something wrong in the way a make the call) with the following data:
Type: XHR
Status: 207
Request Method: PROPFIND
Status Code: 207 Multi-Status
Remote Address: 10.107.50.24:443
Referrer Policy: strict-origin-when-cross-origin
Connection: close
Date: Thu, 21 Oct 2021 12:44:55 GMT
Server: nginx/1.4.6 (Ubuntu)
Transfer-Encoding: chunked
Accept: text/plain
Accept-Encoding: gzip, deflate, br
Accept-Language: en,de-DE;q=0.9,de;q=0.8,en-US;q=0.7
Access-Control-Allow-Headers: Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With
Access-Control-Allow-Methods: DELETE, POST, GET, OPTIONS
Access-Control-Allow-Origin: *
Authorization: Basic dXNlcjpwYXNzd2Q=
Connection: keep-alive
Cookie: d8522de4f35024212f5d0e7f0b289d29=3570640034998b52c04921bcd836972d
Depth: 1
Host: https://mywebdavurl.com/
Referer: http://localhost:3001/
sec-ch-ua: "Google Chrome";v="95", "Chromium";v="95", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
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/95.0.4638.54 Safari/537.36
Of course, I need to get rid of this hack that was just for debugging purposes and let me understand that I can use the WebDAV library inside a react application and that there are some other kinds of problems.
Any help will be appreciated. I provided all the information I have but if you need more, I can look for other stuff.

XMLHttpRequest return 403 on new server

I use a library (orakupload) to upload photos. This makes a query through XMLHttpRequest to a php file from the same library, which save the image.
On the old server it works perfectly, but we have changed the server and it has stopped working.
Calling the php file I get a 403 Forbidden. This file is in exactly the same folder as the Js that calls it (logically, also the same server).
I have searched and tried everything, but I can't get it to not return the error, let's see if you can help me.
The XMLHttpRequest:
var xhr = new XMLHttpRequest();
xhr.open("POST", settings.orakuploader_path+"orakuploader.php?filename="+encodeURIComponent(file.name)+"&path="+settings.orakuploader_path+"&resize_to="+settings.orakuploader_resize_to+"&thumbnail_size="+settings.orakuploader_thumbnail_size+"&main_path="+settings.orakuploader_main_path+"&thumbnail_path="+settings.orakuploader_thumbnail_path+"&watermark="+settings.orakuploader_watermark+"&orakuploader_crop_to_width="+settings.orakuploader_crop_to_width+"&orakuploader_crop_to_height="+settings.orakuploader_crop_to_height+"&orakuploader_crop_thumb_to_width="+settings.orakuploader_crop_thumb_to_width+"&orakuploader_crop_thumb_to_height="+settings.orakuploader_crop_thumb_to_height, true);
xhr.send(file);
xhr.onreadystatechange = function()
{
...
If I open the path that creates, and open directly in chrome, it executes the php file without problem.
So I think it must not be the htaccess problem.
I thought that for some reason it could be a CORS problem, but I add the headers to the php file and it continues with the problem:
header('Access-Control-Allow-Origin: *');
header("Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept");
header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE');
Finally, I leave here the information of the headers in the query, in case it can be of help:
General
Request URL: https://www.XXXXXX.com/intranet/orakuploader/orakuploader.php?filename=aaaa.png&path=/intranet/orakuploader/&resize_to=0&thumbnail_size=0&main_path=/intranet/files&thumbnail_path=/intranet/files/tn&watermark=&orakuploader_crop_to_width=1920&orakuploader_crop_to_height=1420&orakuploader_crop_thumb_to_width=200&orakuploader_crop_thumb_to_height=200
Request Method: POST
Status Code: 403 Forbidden
Remote Address: 52.121.xx.xx:xxx
Referrer Policy: strict-origin-when-cross-origin
Response Header
Connection: Keep-Alive
Content-Length: 318
Content-Type: text/html; charset=iso-8859-1
Date: Wed, 21 Jul 2021 12:33:40 GMT
Keep-Alive: timeout=5, max=53
Server: Apache
X-Frame-Options: SAMEORIGIN, SAMEORIGIN
Request Header
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: es,ca;q=0.9
Connection: keep-alive
Content-Length: 200316
Content-Type: image/png
Cookie: xxxxxxx
Host: www.XXXXXX.com
Origin: https://www.XXXXXX.com
Referer: https://www.XXXXXX.com/intranet/prop/1193
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
EDIT
If I disconnect the ssl certificate, it does not save the image, but I do not receive the 403 error, could the cause be here?

I have found the problem, I leave it here in case it helps someone:
Finish looking for the apache "mod_security" module. And I found that one of rules was blocking the request.

Fetch request failing for DELETE method even though CORS headers are present

I am trying to make a Cross Origin delete request via fetch and its failing with a 403 (Exact Error Access to fetch at 'http://localhost:1180/api/deleteResource/name/something/city/Shenzhen%202' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.)
Here are my request and response headers -
General -
Request URL: http://localhost:1180/api/deleteResource/name/something/city/Shenzhen%202
Request Method: OPTIONS
Status Code: 403 FORBIDDEN
Remote Address: [::1]:1180
Referrer Policy: no-referrer-when-downgrade
Response Headers-
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: Content-Type,Content-Length,Server,Date
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Type, Content-Length, Server, Date
Content-Length: 43
Content-Type: application/json
Content-Type: application/json; charset=utf-8
Date: Mon, 18 Nov 2019 07:24:51 GMT
Server: Werkzeug/0.14.1 Python/3.6.5
X-Content-Type-Options: nosniff
Request headers-
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Access-Control-Request-Headers: access-control-allow-methods,access-control-allow-origin
Access-Control-Request-Method: DELETE
Connection: keep-alive
Host: localhost:1180
Origin: http://localhost:3000
Referer: http://localhost:3000/
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
Whereas my GET requests are working just fine -
General -
Request URL: http://localhost:1180/api/getResources
Request Method: GET
Status Code: 200 OK
Remote Address: [::1]:1180
Referrer Policy: no-referrer-when-downgrade
Response Headers -
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: Content-Type,Content-Length,Server,Date
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Type, Content-Length, Server, Date
Content-Length: 6164
Content-Type: application/json
Content-Type: application/json; charset=utf-8
Date: Mon, 18 Nov 2019 07:24:44 GMT
Server: Werkzeug/0.14.1 Python/3.6.5
X-Content-Type-Options: nosniff
Request Headers -
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Host: localhost:1180
Origin: http://localhost:3000
Referer: http://localhost:3000/
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
I do understand that the preflight check doesn't happen for Simple GET & POST requests due to which my GET is successful, but still I don't get why my DELETE is failing as it has been allowed from the server. Can someone help me understand what the problem here is?

Your DELETE request has access-control-allow-methods,access-control-allow-origin headers, But In response, It only allows Content-Type, Content-Length, Server, Date headers. That's why it's throwing doesn't pass access control error.
Solution
Set Access-Control-Allow-Headers to allow Content-Type,Content-Length,Server,Date,access-control-allow-methods,access-control-allow-origin.
I am not sure about your Back-End technology, I can't provide code to allow above headers without knowing your back-end technology

Hapi.js v17 CORS Pre-flight not returning Access-Control-Allow-Origin header [duplicate]

I have an ajax file upload using (Dropzone js). which sends a file to my hapi server. I realised the browser sends a PREFLIGHT OPTIONS METHOD. but my hapi server seems not to send the right response headers so i am getting errors on chrome.
here is the error i get on chrome
XMLHttpRequest cannot load http://localhost:3000/uploadbookimg. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access.
this is the hapi js route handler
server.route({
path: '/uploadbookimg',
method: 'POST',
config: {
cors : true,
payload: {
output: 'stream',
parse: true,
allow: 'multipart/form-data'
},
handler: require('./books/webbookimgupload'),
}
});
In my understanding hapi js should send all cors headers from the Pre-fight (OPTIONS) request.
Cant understand why its is not
Network request /response from chrome
**General**
Request Method:OPTIONS
Status Code:200 OK
Remote Address:127.0.0.1:3000
**Response Headers**
view parsed
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
cache-control: no-cache
vary: accept-encoding
Date: Wed, 27 Apr 2016 07:25:33 GMT
Connection: keep-alive
Transfer-Encoding: chunked
**Request Headers**
view parsed
OPTIONS /uploadbookimg HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: POST
Origin: http://localhost:4200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.87 Safari/537.36
Access-Control-Request-Headers: accept, cache-control, content-type
Accept: */*
Referer: http://localhost:4200/books/upload
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Thanks in advance

The hapi cors: true is a wildcard rule that allows CORS requests from all domains except for a few cases including when there are additional request headers outside of hapi's default whitelist:
["accept", "authorization", "content-type", "if-none-match", "origin"]
See the cors option section in the API docs under route options:
headers - a strings array of allowed headers ('Access-Control-Allow-Headers'). Defaults to ['Accept', 'Authorization', 'Content-Type', 'If-None-Match'].
additionalHeaders - a strings array of additional headers to headers. Use this to keep the default headers in place.
Your problem is that Dropzone sends a couple of headers along with the file upload that aren't in this list:
x-requested-with (not in your headers above but was sent for me)
cache-control
You have two options to get things working, you need to change something on either the server or the client:
Option 1 - Whitelist the extra headers:
server.route({
config: {
cors: {
origin: ['*'],
additionalHeaders: ['cache-control', 'x-requested-with']
}
},
method: 'POST',
path: '/upload',
handler: function (request, reply) {
...
}
});
Option 2 - Tell dropzone to not send those extra headers
Not possible yet through their config but there's a pending PR to allow it: https://github.com/enyo/dropzone/pull/685

I want to add my 2 cents on this one as the above did not fully resolve the issue in my case.
I started my Hapi-Server at localhost:3300. Then I made a request from localhost:80 to http://localhost:3300/ to test CORS. This lead to chrome still blocking the ressource because it said that
No 'Access-Control-Allow-Origin' header is present on the requested
resource
(which was not true at all).
Then I changed the XHR-Request to fetch the url to a url for which I actually created a route inside HapiJS which - in my case - was http://localhost:3300/api/test. This worked.
To overgo this issue I created a "catch-all" route in HapiJS (to overgo the built-in 404 catch).
const Boom = require('Boom'); //You can require Boom when you have hapi
Route({
method: '*',
path: '/{any*}',
handler: function(request, reply) {
reply(Boom.notFound());
}
})

Refused to get unsafe header "Location" in chrome and no content in firefox

I am trying to upload an file to ovh object storage (openstack swift), but run into issues.
In Chrome I get:
Refused to get unsafe header "Location"
I tried solving this with by adding 'Access-Control-Expose-Headers': 'Location' to the request headers. But error remains.
In Firefox I get following in the console:
OPTIONS XHR
[HTTP/1.1 200 OK 421ms]
Request Headers:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Request-Headers: access-control-expose-headers,tus-resumable,upload-length,upload-metadata,x-auth-token
Access-Control-Request-Method: POST
Connection: keep-alive
Host: storage.gra1.cloud.ovh.net
Origin: http://localhost:8089
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Response Headers:
Allow: HEAD, GET, PUT, POST, OPTIONS, DELETE
Content-Length: 0
Date: Thu, 01 Feb 2018 14:55:05 GMT
X-IPLB-Instance: 12318
X-Openstack-Request-Id: txe638462886d66db5ad3c6-005a732a49
X-Trans-Id: txe638462886d66db5ad3c6-005a732a49
access-control-allow-headers: x-auth-token, upload-metadata, upload-length, tus-resumable, access-control-expose-headers
access-control-allow-methods: HEAD, GET, PUT, POST, OPTIONS, DELETE
access-control-allow-origin: *
vary: Access-Control-Request-Headers
POST XHR
[HTTP/1.1 204 No Content 579ms]
Request Headers
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Expose-Headers: Location
Connection: keep-alive
Content-Length: 0
Host: storage.gra1.cloud.ovh.net
Origin: http://localhost:8089
Referer: http://localhost:8089/mywebpage
Tus-Resumable: 1.0.0
Upload-Length: 4885581
Upload-Metadata: modelId RmF2b3usrGVz,name MjIyLmpwZz==,type aW1hZ2UvanBlZz==
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
X-Auth-Token: aSecret000000001
Response Headers
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: x-trans-id, content-language, X-Container-Read, expires, X-Storage-Policy, last-modified, etag, x-timestamp, pragma, cache-control, content-type, x-openstack-request-id
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Thu, 01 Feb 2018 14:55:05 GMT
X-IPLB-Instance: 12309
X-Openstack-Request-Id: txe638462886d66db5ad3c6-005a732a49
X-Trans-Id: txe638462886d66db5ad3c6-005a732a49
I do not know whether 'No Content' means successful, or something wrong, anyway the file is not send, so probably the last.
My questions:
- How to get rid of the Chrome error message
- How to get the file across.

Access-Control-Expose-Headers should be added to the response by the requested resource's provider (OpenStack Swift), not the client. What you need to do is to configure OpenStack Swift to add this header to its responses.
So how are you going to do it? OpenStack allows you to set/append custom values for Access-Control-Allow-Origin, Access-Control-Max-Age and Access-Control-Expose-Headers for each container. Please see this official document for details.
Example:
Let's create a container and set the custom header values we want to add to the Access-Control-Expose-Headers in the response to the requests made for the objects in this container.
curl -i -X PUT -H "X-Auth-Token: yourtoken" \
-H "X-Container-Meta-Access-Control-Expose-Headers: Location" \
http://192.168.56.3:8080/v1/AUTH_test/cont1
Now for every object you create in this container, you will see Location listed in Access-Control-Expose-Headers and get rid of the error message in Chrome.
You can see the rest of the CORS headers you can configure for each container, in the documentation I linked above.