Having some major CORS problems with Google Chrome lately:
Access to XMLHttpRequest at '...' from origin '...' has been blocked
by CORS policy: Response to preflight request doesn't pass access
control check: It does not have HTTP ok status.
The weird thing is that the request works perfectly on Mozilla Firefox.
I tried to add different headers to the server including:
Access-Control-Allow-Headers: Content-Type,Authorization,X-Requested-With,Accept,Access-Control-Request-Method,Origin,Access-Control-Request-Headers
Access-Control-Allow-Methods: GET, POST, DELETE, PUT,OPTIONS,HEAD
Access-Control-Allow-Origin: *
Also before the "CORS Block" there's an OPTIONS request method Google Chrome sends my server but here i get a 500 server error:
javax.servlet.ServletException: A MultiException has 4 exceptions.
They are:
javax.ws.rs.ProcessingException: Error creating a JAXBContext for wadl processing.
java.lang.IllegalStateException: Unable to perform operation: create on
org.glassfish.jersey.server.wadl.internal.WadlApplicationContextImpl
java.lang.IllegalArgumentException: While attempting to resolve the dependencies of
org.glassfish.jersey.server.wadl.processor.WadlModelProcessor$OptionsHandler
errors were found
java.lang.IllegalStateException: Unable to perform operation: resolve on
org.glassfish.jersey.server.wadl.processor.WadlModelProcessor$OptionsHandler
org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:432)
org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:370)
org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:389)
org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:342)
org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:229)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
com.isyndix.rest.CORSFilter.doFilter(CORSFilter.java:40)
Does this have anything to do with it?
Thanks in advance for your help and time.
Cheers!
So apparently it had something to do with the OPTIONS-preflight not being handled right in the server back-end.
I have implemented the OPTIONS method in the REST endpoint:
#OPTIONS
public Response options() {
return Response.ok().build();
}
Keep in mind this is not a very good way of handling the problem because you need to implement this for every endpoint in your API.
But I didn't find a better solution and this works for me.
Cheers!
Related
I am trying to send an API request to the external service using flow in salesforce but when I debug my flow it returns the below error
Error Occurred: Callout failed for invocable action testing3.post-vacancy-id. Expected declared response media type application/json, but got application/problem+json; charset=utf-8 for operation post-vacancy-id and service testing3
I have not specified the content-type in the header (cause I don't know how to define that in the header in flow) but I found that it will take the default content-type as application/JSON and also I have checked the body of the API request it is work fine when sending it from the postman.
I have searched regarding this but didn't find anything on the web, any help will be appreciated here.
thanks!!
It appears that in a recent Chrome release, (or at least recently when making calls to my API --- haven't see it until today), Google is throwing warnings about CORB requests being blocked.
Cross-Origin Read Blocking (CORB) blocked cross-origin response [domain] with MIME type text/plain. See https://www.chromestatus.com/feature/5629709824032768 for more details.
I have determined that the requests to my API are succeeding, and that it's the pre-flight OPTIONS request that is triggering the warning in console.
The application which is calling the API, is not explicitly making the OPTIONS request, rather I have come to understand this is enforced by the browser when making a cross-origin request and is done automatically by the browser.
I can confirm that the OPTIONS request response does not have a mime-type defined. However, I am a little confused as it is my understanding that an OPTIONS response, is only headers, and does not contain a body. I do not understand why such a request would require a mime-type to be defined.
Moreover, the console warning says the request was blocked; yet the various POST and GET requests, are succeeding. So it looks as though the OPTIONS request isn't actually being blocked?
This is a three-part question:
Why does an OPTIONS request require a mime-type to be defined, when there is no body response?
What should the mime-type be for an OPTIONS request, if plain/text is not appropriate? Would I assume application/json to be correct?
How do I configure my Apache2 server to include a mime-type for all pre-flight OPTIONS requests?
I have gotten to the bottom of these CORB warnings.
The issue is related, in part, to my use of the content-type-options: nosniff header. I set this header in order to stop the browser from trying to sniff the content-type itself, thereby removing mime-type trickery, namely with user-uploaded files, as an attack vector.
The other part of this, is related to the content-type being returned application/json;charset=utf-8. Per Google's documentation, it notes:
A response served with a "X-Content-Type-Options: nosniff" response header and an incorrect "Content-Type" response header, may be blocked.
Based on this, I set out to double check IANA's site on acceptable media types. To my surprise, I discovered that no charset parameter was ever actually defined in any RFC for the application/json type, and further notes:
No "charset" parameter is defined for this registration. Adding one really has no effect on compliant recipients.
Based on this, I removed the charset from the content-type: application/json and can confirm the CORB warnings stopped in Chrome.
In conclusion, it would appear that per a recent Chrome release, Google has opted to start treating the mime-type more strictly than it has in the past.
Lastly, as a side note, the reason all of our application requests still succeeds, is because it appears Cross-Origin Read Blocking isnt actually enforced in Chrome:
In most cases, the blocked response should not affect the web page's behavior and the CORB error message can be safely ignored.
Was having the same issue.
The problem I had was due to the fact the API was answering to the preflight with 200 OK but was an empty response without the Content-Length header set.
So, either changing the preflight response status to 204 No Content or by simply setting the Content-Length: 0 header solved the issue.
We have an AWS API Gateway API that works for CORS most of the time. The only exception is when POSTing with invalid JSON, when CORS headers are missing from the response. If it is a valid JSON but it fails data validation, then the CORS headers are correctly set. I tried to reset the root resource by 'enable CORS' for root resource and redeploy, the same situation.
Just wondering if anyone has seen this before and how to fix it. Thanks
found the answer myself. If APIG has not reached integration in this case, need to customize the gateway response
https://docs.aws.amazon.com/apigateway/latest/developerguide/customize-gateway-responses.html
I'm writing a API call with Fetch() to download a file from another Domain. The process is: A fetch() method is calling in DomainA to an API in DomainB, then the API returns the response with location in repsonse's header, the location is an url of DomainC.
In Chrome and IE, it works well. Based on the Network Inspection, we can see 3 http requests here.
A. An OPTIONS request to the API, the response Status code 200;
B. An GET request to the API, and the response status code is 302 and
in the response Header, location property contains the target file
location (http url).
C. A request to the target file location to download the file.
But in Firefox and Edge, we can only see the request A) and B). Both of their responses are expected. While there is no 3rd request to download the data. Within debugging, we can see an error is thrown in the fetch().catch(error){}, the error is TypeError:
In Firefox:
TypeError: NetworkError when attempting to fetch resource. In Edge:
TypeError: Failed to fetch
I just did some investigation on this issue.
According to Http-redirect fetch, it should work well since CORS is configured correctly. I guess Firefox or Edge may implement their native fetch() method which leads an failure here.
Does anyone know what's going on here? Thanks.
I'm calling a SonarQube API using JSONP module.
this.jsonp.get('https://sonarqube.com/api/projects/index')
.subscribe(res => console.log(res));
I previously used Http module of Angualar2, which caused the browser to throw the error
Origin http://localhost:4200 is not allowed by Access-Control-Allow-Origin
To overcome this problem I found out that you could use JSONP or CORS or launch chrome with --disable-web-security of which I could find sufficient typescript support to get started with JSONP. But I later found that JSONP expects MIME-type to be application/javascript when I got the following error
Refused to execute script from 'https://sonarqube.com/api/projects/index' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
Is there a way to force JSONP module to fetch JSON data and parse it successfully?
Solution 1: Enable JSONP in Server
I found out that this isn't possible. JSONP is just one way to get over the Cross-Origin-Requests problem, but it requires a modification to the server configuration/implementation to serve JSONP data (MIME-type: application/javascript).
Solution 2: Enable CORS support in server
CORS is a more recent solution to the Cross-Origin-Requests problem. It can be resolved by adding the following headers to the server:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST,GET,PUT,DELETE
Access-Control-Allow-Headers: Authorization, Lang
Solution 3: Using a reverse proxy
One suggestion I came across in my search was to use the server to fetch the Cross-Origin-Request. I didn't have control over the server code. Then I came across the concept of Reverse Proxies, found the cors-anywhere package in an angular forum. The reverse proxy fetches these resources on behalf of your front-end and adds the CORS headers to the proxied request.