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
Related
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!
I used to use the XML endpoint because it provided review dates for each review called 'updated'. This is not contained in the JSON endpoint. However, the XML endpoint stopped working. I get the error seen below:
Web Server Error
Description: The host did not return the document correctly.
Has anyone experienced the same issue? Any workarounds? Do you anticipate this will ever be fixed by Apple? Do you think the JSON endpoint might be taken down any time soon?
XML Endpoint (Broken)
https://itunes.apple.com/us/rss/customerreviews/id=1145275343/mostrecent/xml
JSON Endpoint (Working)
https://itunes.apple.com/us/rss/customerreviews/id=1145275343/mostrecent/json
It appears the XML endpoint is up and running again. No more Web Server Error. Hopefully the endpoint stays up.
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.
I am implementing an RESTful Webservice which returns every content formatted as JSON. I am also using Spring OAuth2, but all error messages like invalid access token etc are returned in XML format. How can I return these OAuth2 errors as JSON?
By the way, the access tokens are returned as JSON String.
We have faced the same problem.
After hours and hours of configuring it on server side we have found better way to migrate this nuisance.
Error messages for OAuth2 for Spring defaults to xml but with one simple trick you can change them to JSON: by sending Accept: application/json in request headers.
Hope I helped a bit.
I'm making a request to an authorized Instagram account to display images on a site. Originally, I was running into No 'Access-Control-Allow-Origin' when using Angular's $http.get(....
From Matt's answer in this question, It seems that I can use getJSON, or Angular $http.jsonp, to bypass this issue. That Guy's answer also says "JSONP is really a simply trick to overcome XMLHttpRequest same domain policy".
So, I'm no longer getting that problem, and am getting a json payload:
{"pagination":{"next_url":"https:\/\/api.instagram.com... etc
But am getting a very ambiguous error:
Uncaught SyntaxError: Unexpected token :
This is a response from the Instagram API, so I'm not sure why there'd be a syntax error on the inbound json. Also, It's hard to locate the error since the jsonp response is all on a single line... where the error is reported.
The preview shows that I'm getting a full payload:
I found the issue. Unfortunately there are no JavaScript libraries to help with this, but in the Instagram API docs, for JSONP you can wrap the response with a callback so that the json payload will be wrapped in <script> tags (more info on jsonp here), therefore not blocked by Access Control Allow Origin.
https://api.instagram.com/v1/tags/coffee/media/recent?access_token=ACCESS-TOKEN&callback=callbackFunction
Response:
callbackFunction({
...
});
So, in your http request URI, you add in a callback parameter. Since I am using Angular, their docs for $http.jsonp() requests specify the callback string as "JSON_CALLBACK".
So, my request URL for Angular would be:
$http.jsonp(
'https://api.instagram.com/v1/tags/coffee/media/recent?
access_token=ACCESS-TOKEN&callback=JSON_CALLBACK')
.success(function(data) {...