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.
Related
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.
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
it is my first time using Graphql in production and it is giving me the following problem.
The antecedents:
It is a Meteor application that uses Apollo - Graphql to do search, Auth, etc.
I am deploying on a heroku server.
The DNS is in digitalocean and I use a custom domain.
On the heroku server and on the localhost, everything works fine, no problem.
The problem:
when I used the custom domain, the content was blocked and a cors policy error appeared in the browser console, apparently a problem with the origin of the callback, so I investigated and configured the headers using the Meteor resources (webapp) and the source problem was solved, however it does not give me the Ok status, so the "OPTIONS" operation ends up blocking the other operations.
The code:
This code is running at: import/startup/server/register-api.js
WebApp.rawConnectHandlers.use(function(req, res, next) {
res.setHeader("Access-Control-Allow-Origin", "*");
res.setHeader('Access-Control-Allow-Methods', "POST");
return next();
});
This is the image of console browser error
this is the bloqued operations:
General: request
Request URL: https://servername.herokuapp.com/graphql
Request Method: OPTIONS
Status Code: 405 Method Not Allowed
Remote Address: 34.193.254.1:443
Referrer Policy: no-referrer-when-downgrade
Response Header
Access-Control-Allow-Methods: POST,GET,PUT,DELETE
Access-Control-Allow-Origin: http://www.domainname.co
Allow: GET, POST
Connection: keep-alive
Date: Fri, 23 Nov 2018 17:13:52 GMT
Server: Cowboy
Transfer-Encoding: chunked
Via: 1.1 vegur
X-Powered-By: Express
Request Header
Provisional headers are shown
Access-Control-Request-Headers: content-type,meteor-login-token
Access-Control-Request-Method: POST
Origin: http://www.domainname.co
Referer: http://www.domainname.co/search-panel?lat=xxxx&lng=xxx&address=xxxx&category=xxx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
thank you very much to all
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.
On my development server written in Rails 3, I set the CORS headers in my application controller to allow cross-domain access:
class ApplicationController < ActionController::Base
before_filter :cross_domain_setup
# ...
def options_request
head :no_content
end
def cross_domain_setup
response.headers["Access-Control-Allow-Origin"] = "*"
response.headers["Access-Control-Allow-Methods"] = "GET, PUT, POST, DELETE, OPTIONS"
response.headers["Access-Control-Allow-Headers"] = "Content-Type, X-Requested-With"
end
# ...
end
# in routes.rb:
match "*path" => "application#options_request", constraints: { method: "OPTIONS" }
Here's my frontend code (Sencha Touch):
// note: this should probably be done using MVC, but my server doesn't
// have a RESTful API for this particular resource
var statusText = accepted ? "accepted" : "ignored";
Ext.Ajax.request({
url: "http://localhost:3000/friends/requests",
method: "PUT",
params: {
friend_request: {
_id: friendRequest.internalId,
status: statusText
}
},
success: success,
failure: failure
});
This sends the following HTTP request:
OPTIONS /friends/requests?_dc=1388320908671 HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Access-Control-Request-Method: PUT
Origin: http://localhost
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
Access-Control-Request-Headers: x-requested-with, content-type
Accept: */*
Referer: http://localhost/path/to/index.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
My server responds with:
HTTP/1.1 204 No Content
Date: Sun, 29 Dec 2013 12:41:48 GMT
Status: 204 No Content
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With
X-UA-Compatible: IE=Edge
Cache-Control: no-cache
Set-Cookie: blahblahblah; path=/; HttpOnly
X-Request-Id: 01157976a93af661045eefdf4b8beb2e
X-Runtime: 0.016029
which all looks correct. So how come I get the following error in the Developer Tools?
XMLHttpRequest cannot load http://localhost:3000/friends/requests?_dc=1388320920825. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.
Not all requests are blocked. I haven't yet figured out why.
What could be going wrong?
I think what was happening was that the requested resource was producing a 500 internal server error (can't convert symbol into integer, etc etc), but this showed up as a blocked request maybe because the CORS headers weren't being sent due to the 500 error?
Whatever the case, using the rack-cors gem seems to have solved the problem. Now my front end receives the 500 error as expected.