I'm trying to use angularJS with a Jetty backend.
Preflight CORS requests are working fine in chrome but in firefox I get this CORS error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://remote.machine:8080/api/v1/provisioning/users/current-user. This can be fixed by moving the resource to the same domain or enabling CORS.
The Headers for the options request are as follows:
HTTP/1.1 200 OK
Date: Wed, 24 Sep 2014 16:06:12 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Frame-Options: DENY
Access-Control-Allow-Methods: GET, PUT, POST, OPTIONS, DELETE
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Credentials: true
Set-Cookie: JSESSIONID=eyv8cpnnfphy1b0121uzt293y;Path=/
Content-Length: 0
Server: Jetty(9.2.2.v20140723)
The angular request is set up as follows:
$http.get(AS_API_URL + '/provisioning/users/current-user', {
headers: {
'Authorization': 'Basic ' + base64EncodedAuth
}
});
For some reason these headers work fine in Chrome but not in Firefox, does anyone have a clue as to why? Do I need to provide more info?
EDIT:
Musa was right about the Access-Control-Allow-Headers being malformed.
I edited the Jetty Server so the header now reads:
Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
I give my thanks to you Musa, you just saved my day :)
To expand upon Musa's answer in the comments, Firefox is blocking the request because the following header has the header twice instead of once:
Access-Control-Allow-Headers: Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
should be changed to
Access-Control-Allow-Headers: Origin, Authorization, X-Requested-With, Content-Type, Accept
Related
I have a simple post request with axios:
axios.post('my endpoint', values).then(res => console.log(res.headers));
axios is listing those values as headers:
cache-control: "max-age=0, private, must-revalidate"
content-length: "13757"
content-type: "application/xml; charset=utf-8"
but when I check the network tab in chrome, I can see those values under response headers:
access-control-allow-origin: http://localhost:8080
access-control-expose-headers: Total,Total-Pages
cache-control: max-age=0, private, must-revalidate
content-length: 13757
content-type: application/xml; charset=utf-8
date: Thu, 02 Sep 2021 19:37:42 GMT
x-envoy-upstream-service-time: 385
x-request-id: FqEYfGCtbcHGzzwASr4C
I need to access the x-request-id header, but there is no way to get this with axios or fetch.
I saw some messages about the header being blocked by cors, but I have X-Request-Id in my access-control-allow-headers
Someone has any idea how to get this header with axios?
I think you have to specify this on the server so that axios has access to the specific headers you require.
https://stackoverflow.com/a/37931084/8818020
I have a problem with Chrome - in the network tab it only displays an empty Access-Control-Exposed-Headers header.
In postman the header's value is visible:
When trying to access the ETag header through the getResponseHeader('ETag') method of the XMLHttpRequest I'm getting a Refused to get unsafe header "etag" error. I already ran out of ideas how to fix this. Does anybody know what could be wrong?
EDIT: Apparently that behaviour is caused by the Origin header - when it is present in the request, the Access-Control-Expose-Headers in the response is empty. Unfortunately, I don't have access to the backend code, so I can't provide an example. All response headers:
HTTP/1.1 200 OK
Server: openresty/1.9.7.5
Date: Sun, 03 Sep 2017 13:02:55 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Expose-Headers:
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: *,x-requested-with,Content-Type,If-Modified-Since,If-None-Match,latest_time
Access-Control-Max-Age: 1728000
ETag: "eef3e52bc505031d93da42098f32cc60"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: eb5c7353-0b4b-43c8-b2ff-4763d56d9ec9
X-Runtime: 0.015680
Access-Control-Allow-Credentials: true
Vary: Origin
I am making a POST request from a local https server to an ElasticSearch endpoint which has been configured as follows
http.cors.enabled: true
http.cors.allow-credentials: true
http.cors.allow-origin: "*"
http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers: X-Requested-With, X-Auth-Token, Content-Type, Content-Length, Authorization, Access-Control-Allow-Headers, Accept
The request has headers:
Access-Control-Allow-Headers: Accept, Access-Control-Allow-Headers, Authorization, Content-Type
Content-Type: application/json; charset=utf-8
Accept: application/json; charset=utf-8
Access-Control-Allow-Credentials: true
Authorization: (basic authentication token)
On a POST request, the following error appears: Request header field Access-Control-Allow-Headers is not allowed by Access-Control-Allow-Headers in preflight response.
The network debugger indeed shows that the Access-Control-Allow-Headers header is not present in the response header. The response header:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://dl.dropboxusercontent.com
Vary: Origin
Access-Control-Allow-Methods:
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000
content-length: 0
date: Fri, 29 Apr 2016 14:08:14 GMT
Note that Access-Control-Allow-Headers is not present and Access-Control-Allow-Methods is blank. All possible string formats have been tested, and these headers do not appear.
You should add following signs to your elasticsearch.yml:
http.cors.allow-methods : OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers : Authorization, X-Requested-With,X-Auth-Token,Content-Type, Content-Length
and then restart the es, enjoy!
I finally solved the problem with these config lines in elasticsearch.yml:
http.cors.enabled: true
http.cors.allow-origin: /https?:\/\/(localhost)?(127.0.0.1)?(:[0-9]+)?/
http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers: Authorization, X-Requested-With,X-Auth-Token,Content-Type, Content-Length
As of 2022, according to https://docs.elastic.co/search-ui/tutorials/elasticsearch
try include all headers below
http.cors.allow-origin: "*"
http.cors.enabled: true
http.cors.allow-credentials: true
http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers: X-Requested-With, X-Auth-Token, Content-Type, Content-Length, Authorization, Access-Control-Allow-Headers, Accept, x-elastic-client-meta
In my case, I forget to wrap the end of the line and thus get missing header error.
And this is the top search I got, so just put it here in case anyone made same mistake.
I have a really strange problem. I have a Webservice build with a simple Perl CGI Script as a Wrapper to an API (to allow restricted Cross Origin Control).
Anyway, to allow Cross-Origin Requests I set these headers:
Content-Type: text/plain
Access-Control-Allow-Origin: $origin
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-Requested-With, Content-Type, Accept, Accept-Language, Content-Language
Content-Security-Policy: connect-src *
X-Content-Security-Policy: connect-src *
X-WebKit-CSP: connect-src *
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding, Origin
where my $origin = $ENV{HTTP_ORIGIN} // '*';.
When the Script Requests the expected Ressource, the Response from the Wrapper is the followed (copied from Firefox):
HTTP/1.1 200 OK
Date: Wed, 20 Jan 2016 12:54:48 GMT
Server: Apache
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-Requested-With, Content-Type, Accept, Accept-Language, Content-Language
content-security-policy: connect-src *, frame-ancestors 'self'
X-Content-Security-Policy: connect-src *
X-WebKit-CSP: connect-src *
Access-Control-Max-Age: 1728000
Vary: Accept-Encoding,Origin
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain
The Browser gives me the following error:
XMLHttpRequest cannot load http://www.example.com/cgi-bin/wrapper.pl. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://example2.com' is therefore not allowed access.`
I also tested the call with curl and Postman, but this worked as expected.
The problem is that all Browser seem to ignore the Access-Control-Allow-Origin header, even when he is set.
Okay I found the problem. The Error was that I send the Access-Control-Allow-Origin and Access-Control-Allow-Headers only in the OPTIONS Request, not in the normal POST.
I have the following coffee script which performs some sort of login:
signIn: (url, completion) ->
$.ajax
method: 'GET'
url: url
dataType: 'json'
error: (jqXHR, status, errorThrown) ->
completion false, errorThrown
success: (data)->
completion true, data.Identifier
When I check the given URL in the browser I get a valid JSON Response back.
However, when this call is executed using JavaScript I get the following error in the console . Please note that I have changed the URLs for obfuscation:
XMLHttpRequest cannot load http://my.servicedomain.com/session/someIdentifier?access_token=secret.
Origin http://html.server.net is not allowed by Access-Control-Allow-Origin.
These are my headers, which I get from the my.servicedomain.com server:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 1417
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization
Date: Wed, 10 Jul 2013 14:24:35 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: Keep-Alive
Why do I get this error, even though I have Access-Control-Allow-Origin: * in the response header?
I have just figured out the answer myself. I knew that I had duplicated headers in my response, but I was assuming this would not be a problem.
It looks like this is a Problem according to the CORS Spec:
If the response includes zero or more than one Access-Control-Allow-Origin header values, return fail and terminate this algorithm.
This is also described in this SO Thread:
Will duplicate "Access-Control-Allow-Origin: *" headers break CORS?