I am using Microsoft.AspNet.WebApi.Cors to support cross origin request as per this
https://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api
My web apis are configured to use windows authentication and every request coming from angular has withCredentials set to true. Everything is working with HTTP GET but with PUT request sends preflight request which in getting unauthorised. My question is does Microsoft.AspNet.WebApi.Cors support configuration of OPTION request.
Put this in your Global.asax.cs
(I'm sure you either found a solution or gave up, but this is the link that I found on Google while looking for a solution to this.)
protected void Application_BeginRequest()
{
if (Request.HttpMethod == "OPTIONS")
{
Response.StatusCode = (int)HttpStatusCode.OK;
Response.AppendHeader("Access-Control-Allow-Origin", Request.Headers.GetValues("Origin")[0]);
Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
Response.AddHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
Response.AppendHeader("Access-Control-Allow-Credentials", "true");
Response.End();
}
}
Related
I'm developing a webapp angular-springboot with some other people, and to a few of those certain requests of the app are blocked by the cors with this error:
Access to XMLHttpRequest at 'https://localhost:8443/api/contratto/update' from origin 'http://localhost:4200' 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
so I have researched what a preflight request is and I've added this method to the controller:
#RequestMapping(value = "/update",method = RequestMethod.OPTIONS)
public ResponseEntity<String> preFlightHandler(){
HttpHeaders responseHeaders = new HttpHeaders();
responseHeaders.set("Access-Control-Allow-Origin",
"https://localhost:8443");
return ResponseEntity.ok()
.headers(responseHeaders)
.body("gggg");
}
but it never even gets executed, how do I create a method mapped specifically for preflights?
didn't make a method mapped for that but I solved the error, Im' using the WebSecurityConfigurerAdapter and in the method configure(HttpSecurity http) I added the line
http.cors().configurationSource(request -> new CorsConfiguration().applyPermitDefaultValues());
I have backend API which was accessible with GET, but couldn't be successful with POST, due to PREFLIGHT issue, which incurred CORS blockage.
Thus, in this site,
https://newbedev.com/http-request-from-angular-sent-as-options-instead-of-post#:~:text=HTTP%20request%20from%20Angular%20sent%20as%20OPTIONS%20instead,is%20allowed%20from%20a%20particular%20domain%20as%20follows%3A
I have found that, you just simply play with OPTIONS method, which your browser calls to backend for before "ACTUAL" call. this is called Preflight request.
It uses OPTIONS method instead of get/post/put. Thus, this might be of help.
If you use Node Js Server:
if (req.method == "OPTIONS")
{
res.writeHead(200, {"Content-Type": "application/json"});
res.end();
}
With PHP, I use this code:
if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
header("HTTP/1.1 200 ");
exit;
}
These are my headers in PHP:
header("Access-Control-Allow-Origin: *");
header("Content-Type: application/json; charset=UTF-8");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS");
header("Access-Control-Max-Age: 3600");
header("HTTP/1.1 200");
header("Access-Control-Allow-Headers: Content-Type, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Authorization, X-Requested-With, Origin");
Note the OPTIONS method in the headers.
If you use other language, that might be easy for you using this concept.
That's it.
I am struggling with this issue today as I am implementing a cross-site API call. The worst thing is it works well from my local environment but once on heroku, it fails with the following error:
XMLHttpRequest cannot load https://restcountries.eu/rest/v1/all. Request header field X-XSRF-TOKEN is not allowed by Access-Control-Allow-Headers in preflight response.
Here is the function triggering the call:
let observable = this._http
.get(GEO_API_URL + query)
.map(response => response.json())
.do(val => {
this.cache = val;
observable = null;
})
.share();
return observable;
Any idea ?
Thanks.
Had the same issue.
In my case the reason was that in my Chrome cookies was saved X-XSRF-TOKEN field. And somehow Chrome added header 'Access-Control-Request-Headers: x-xsrf-token' to OPTION request. In Firefox the same page works fine, in incognito mode Chrome - too.
So I've just delete this cookies field (X-XSRF-TOKEN) and that's all.
In my case I had to add the 'x-xsrf-token' value to 'Access-Control-Allow-Headers' header:
header('Access-Control-Allow-Headers: Content-Type, x-xsrf-token')
see AngularJS: POST Data to External REST API
I cleared cookies, this solved problem.
this helped me in java (expose the headers and then include in the allow headers). This will then show in your HttpResponse object:
response.addHeader("Access-Control-Expose-Headers", "header1");
response.addHeader("Access-Control-Expose-Headers", "header2");
response.addHeader("Access-Control-Expose-Headers", "header3");
response.addHeader("Access-Control-Allow-Headers", "Origin, header1, header2, header3, X-Requested-With, Content-Type, Accept");
The reason is that x-xsrf-token keyword is not in response header Access-Control-Allow-Headers.
I solved this problem in java using following solution:
rsp.setHeader("Access-Control-Allow-Methods", "GET,HEAD,POST,OPTIONS,PUT,DELETE,TRACE,CONNECT");
rsp.setHeader("Access-Control-Allow-Headers", "cache-control,content-type,hash-referer,x-requested-with, x-xsrf-token");
if ("OPTIONS".equals(req.getMethod())) {
rsp.setStatus(HttpServletResponse.SC_OK);
return;
}
In my app, I am using grails-spring-security-rest plugin and I am currently at the stage of building authentication flow.
If I use a rest client everything works as expected: I am able to login by posting username & password in json and get tokens back. Perfect!
Now, I am trying to integrate this whole thing with the web form and, of course, the browser sends preflight OPTIONS request.
I have a simple interceptor setup:
#GrailsCompileStatic
class CorsInterceptor {
int order = HIGHEST_PRECEDENCE
CorsInterceptor() {
matchAll() // match all controllers
//.excludes(controller:"login") // uncomment to add exclusion
}
boolean before() {
String origin = request.getHeader("Origin");
boolean options = "OPTIONS".equals(request.getMethod());
if (options) {
if (origin == null) return;
response.addHeader("Access-Control-Allow-Headers", "origin, authorization, accept, content-type, x-requested-with");
response.addHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS");
response.addHeader("Access-Control-Max-Age", "3600");
}
response.addHeader("Access-Control-Allow-Origin", origin == null ? "*" : origin);
response.addHeader("Access-Control-Allow-Credentials", "true");
true // proceed to controller
}
boolean after() { true }
void afterView() {
// no-op
}
}
The interceptor works perfectly got valid get requests and adds the headers into the response. However, when I am trying to senf this:
curl -X "OPTIONS" "http://localhost:8080/api/login" \
-H "Origin: http://localhost:3000" \
-H "Content-Type: application/json" \
-d "{\"username\":\"customer\",\"password\":\"password\"}"
I am always getting 405 Method Not Allowed back and the execution is not even getting to interceptor at all.
My assumption is that the login controller provided by the plugin is not allowing that, and I need to put an additional URL mapping to overcome this problem. My problem is, what this mapping support to look like?
Also, it is possible to setup mapping that will work for all OPTIONS requests, so I don' need to specify them one by one?
Given all that, it is only my assumption... Am I even in the right direction with it?
Thanks,
this problem was faced by many other users as well and was repeatedly asked on github and slack channels. I've created a sample example which has CORS filter in under src/ directory and I've registered it as spring bean. Here is github repo with example app. The Cors filter code is below
#Priority(Integer.MIN_VALUE)
class CorsFilter extends OncePerRequestFilter {
#Override
protected void doFilterInternal(HttpServletRequest req, HttpServletResponse resp, FilterChain chain)
throws ServletException, IOException {
String origin = req.getHeader("Origin");
boolean options = "OPTIONS".equals(req.getMethod());
if (options) {
if (origin == null) return;
resp.addHeader("Access-Control-Allow-Headers", "origin, authorization, accept, content-type, x-requested-with");
resp.addHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS");
resp.addHeader("Access-Control-Max-Age", "3600");
}
resp.addHeader("Access-Control-Allow-Origin", origin == null ? "*" : origin);
resp.addHeader("Access-Control-Allow-Credentials", "true");
if (!options) chain.doFilter(req, resp);
}
}
Register this as spring bean in resources.groovy file as below:
beans = {
corsFilter(CorsFilter)
}
Here is the question asked on github repo of this plugin.
Update
Grails3 CORS interceptor plugin has been update to include SpringSecurityCorsFilter. For details of how to use, refer to this sample
This plugin is much better than the servlet filter I've written above.
Shurik, the 'filters' you speak of are now called 'interceptors' to match more common nomenclature. This 'filter' is NOT deprecated as this is an 'ACTUAL' filter in Grails/SpringBoot. This is why they deprecated the Interceptors from being called this because of all the naming confusion.
I'm struggling with CORS issue. I make a request from js to a different domain, the method allows cross domain request and all works fine with GET but not with POST request. Looks like OPTIONS method is called before the POST and return standard error
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.
return Response.ok().entity(c).header("Access-Control-Allow-Origin", "*")
.header("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS")
.header("Access-Control-Allow-Headers", "Content-Type, x-xsrf-token, X-Requested-With, Accept, Expires, Last-Modified, Cache-Control").build();
On the client side I use angularjs
$http.post(url, data).success(...)
But also tried with
$.ajax({type:'POST',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json'
}...})
the same result. what else can I do to fix POST request?
Add the below code to your Angular JS application config file
$httpProvider.defaults.useXDomain = true;
delete $httpProvider.defaults.headers.common['X-Requested-With'];
My backbone.js application throwing an HTTP OPTIONS not found error when I try to save a model to my restful web service that's located on another host/URL.
Based on my research, I gathered from this post that :
a request would constantly send an OPTIONS http request header, and not trigger the POST request at all.
Apparently CORS with requests that will "cause side-effects on user data" will make your browser "preflight" the request with the OPTIONS request header to check for approval, before actually sending your intended HTTP request method.
I tried to get around this by:
Settting emulateHTTP in Backbone to true.
Backbone.emulateHTTP = true;
I also allowed allowed all CORS and CSRF options in the header.
header('Access-Control-Allow-Origin: *');
header("Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS");
The application crashed when the Backbone.emulateHTTP line of code was introduced.
Is there a way to respond to OPTIONS request in CodeIgniter RESTServer and are there any other alternatives to allow either disable this request from talking place?
I found this on Github as one solution. I am not sure if I should use it as it seems a bit outdated.
I encountered exactly the same problem. To solve it I have a MY_REST_Controller.php in core and all my REST API controllers use it as a base class. I simply added a constructor like this to handle OPTIONS requests.
function __construct() {
header('Access-Control-Allow-Origin: *');
header("Access-Control-Allow-Headers: X-API-KEY, Origin, X-Requested-With, Content-Type, Accept, Access-Control-Request-Method");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE");
$method = $_SERVER['REQUEST_METHOD'];
if($method == "OPTIONS") {
die();
}
parent::__construct();
}
This just checks if the request type is OPTIONS and if so just dies out which return a code 200 for the request.
You can also modify the $allowed_http_methods property in your subclass to exclude the options method. Previous versions of REST_controller did nothing with OPTIONS and adding this line seems to mimic that behavior:
protected $allowed_http_methods = array('get', 'delete', 'post', 'put');
I solved in this way:
header('Access-Control-Allow-Origin: *');
header("Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE");
header("Access-Control-Allow-Headers: X-API-KEY, Origin, X-Requested-With, Content-Type, Accept, Access-Control-Request-Method, x_requested_with");
if ( "OPTIONS" === $_SERVER['REQUEST_METHOD'] ) {
die();
}
Pay attention to add x_requested_with in Access-Control-Allow-Headers.