Following is the request i used so far
$http.get(url)
.success(function (data){})
.error(function (data){})
works without any CORS issues. My server side Allows all origins, methods, all headers
when i add http header like
$http.get(url, { headers: { "USERID": user, "SESSIONID": sessionId}})
the request changes into OPTIONS method when i see in chrome dev tools network tab
What is the reason for this? if it is expected then how to add custom http headers.
I have gone thru this link angularjs-performs-an-options-http-request-for-a-cross-origin-resource but it didnt help
Here i am expecting that server should allow different origins . But it is allowing headers, only if i were in a same server. But not sure about this is by angular or by server side.
after headers
$http.get(url,{ headers: { "USERID": user, "SESSIONID": sessionId } })
in chrome dev tools i am seeing like
Request Method:OPTIONS
Status Code:404 Not Found
but without headers
Request Method:GET
Status Code:200 OK
When i do this in REST Client, i can send headers to the backend.
$http({method: 'GET', url: '/someUrl', headers: { "USERID": user, "SESSIONID": sessionId}}).
success(function(data, status, headers, config) {
// this callback will be called asynchronously
// when the response is available
}).
error(function(data, status, headers, config) {
// called asynchronously if an error occurs
// or server returns response with an error status.
});
will work.
$http.get is a shortcut method.
Check the config in the docs
This is a known bug, see for instance https://github.com/angular/angular.js/issues/1585 .
A workaround is to use a jQuery request.
I had the same massive issue when trying to pass header in my get, where it changes get to options and wouldn't work. In order to make it work I added the following in my php api
<?php if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD']) && $_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD'] == 'GET') {
header("Access-Control-Allow-Headers: Authorization, X-Auth-Token");
}
exit;
} ?>
You can allow for any headers that you wish to pass.
Hope this helps
For my particular problem with my C# Web API solution I had to have something handle the Options request. Angular was sending a preflight request method OPTIONS which I did allow in my web.config with
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS, PATCH" />
But that wasn't enough I also included a method to handle the Options Request and I returned nothing
[ResponseType( typeof( void ) )]
public IHttpActionResult OptionsPost() {
return StatusCode( HttpStatusCode.NoContent );
}
Related
I am building an app which uses a Lumen API. On the Lumen project I have two files which I found on the internet whilst looking up how to handle CORS in Lumen.
CorsMiddleware.php:
<?php
namespace App\Http\Middleware;
class CorsMiddleware {
public function handle($request, \Closure $next)
{
$response = $next($request);
$response->header('Access-Control-Allow-Methods', 'HEAD, GET, POST, PUT, PATCH, DELETE');
$response->header('Access-Control-Allow-Headers', $request->header('Access-Control-Request-Headers'));
$response->header('Access-Control-Allow-Origin', '*');
return $response;
}
}
CatchAllOptionsRequestsProvider.php:
<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
/**
* If the incoming request is an OPTIONS request
* we will register a handler for the requested route
*/
class CatchAllOptionsRequestsProvider extends ServiceProvider {
public function register()
{
$request = app('request');
if ($request->isMethod('OPTIONS'))
{
app()->options($request->path(), function() { return response('', 200); });
}
}
}
These two files fixed my initial CORS issue. I am able to perform a GET and receive data from the API. But when I try a POST method to the API I once again get the following error: "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access."
Upon inspecting the network tab in chrome, There are two requests. The first is an OPTIONS request, which I believe is just to get the allowed headers from the server. The second request is my POST request with the correct payload. They both return a status code of 200 OK but I still get the Access-Control error mentioned above.
It works when using POSTMAN to send data to my API, but not when I use Ionic Serve in the browser
For those who are wondering, I am using Ionic's $http method for the call:
MORE CODE.......
var req = {
method: 'POST',
url: APIUrl + 'register',
timeout: timeout.promise,
data: {"name": "Michael"}
}
$http(req).then(function(res) {
.......MORE CODE
Might it be something to do with the server apache config? I have mod_rewrite enabled.
Any help on this would be greatly appreciated. Thanks
If you are in control of the server, you might need to set the required headers there. Depending on which server, this might help:
http://enable-cors.org/server.html
I'm trying to consume my (CORS compatible) RESTful service
#Path("/greeting")
#GET
#Produces("application/json")
public Response greeting() {
String result = "{\"id\":1,\"content\":\"Hello, World!\"}";
return Response.ok() //200
.entity(result)
.header("Access-Control-Allow-Origin", "*")
.build();
}
from my AngularJS application.
function ($scope, $http) {
$scope.dashboard = "ESCO Dashboard";
console.log('start');
// Simple GET request example:
$http({
method: 'GET',
url: 'http://localhost:8080/NobelGrid/api/users/greeting'
}).then(function successCallback(response) {
console.log('success');
$scope.greeting = response.data;
}, function errorCallback(response) {
console.log('error');
});
console.log('end');
}
but I have this error:
XMLHttpRequest cannot load http://localhost:8080/NobelGrid/api/users/greeting. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:63342' is therefore not allowed access.
Using Console Network of Chrome this seems true cause the Response Header is:
Anyway accessing to the REST service from the browser and not from the Angular app, the header is correct
I also tried this tutorial:
https://spring.io/guides/gs/consuming-rest-angularjs/
with their RESTful service (also CORS compatible, they said), but the result is the same.
ps: I'm using WebStorm as IDE.
UPDATE - SOLVED
Writing this handler at server-side:
#Path("/greeting")
#OPTIONS
#Produces("application/json")
public Response greetingOPT() {
return Response.status(200) //200
.header("Access-Control-Allow-Origin", "*")
.header("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS")
.header("Access-Control-Allow-Headers", "X-Requested-With, Content-Type, X-Codingpedia,Authorization")
.build();
}
it works. At the beginning it gives to me another error:
Request header field Authorization is not allowed by Access-Control-Allow-Headers in preflight [..]
but adding Authorization to the Access-Control-Allow-Headers of the GET and POST resolve the problem.
Look at the error message:
Response to preflight request
Look at the Network log:
Request Method: OPTIONS
Look at your API:
#GET
You need to write a handler for the preflight OPTIONS request before the browser will make the GET request to the handler you have written.
I'm trying to do an AJAX request to https://developers.zomato.com/api/v2.1/search referring to Zomato API
The server has headers:
"access-control-allow-methods": "GET, POST, DELETE, PUT, PATCH, OPTIONS",
"access-control-allow-origin": "*"
The problem is that the API requires additional headers set for user-key. But whenever I set custom headers then chrome would do a pre-flight request by sending an OPTIONS request to the above URL which is failing, and thus the AJAX request is failing as well.
If I don't set the headers, then I don't get a CORS error, but rather a forbidden error from server since I'm not setting user-key header.
Any way to go about this catch-22 situation?
Both Jquery and JavaScript way are failing:
$(document).ready(function () {
$.ajax({
url: 'https://developers.zomato.com/api/v2.1/search',
headers: {
'Accept': 'application/json',
'user_key': 'XXXXX'
},
success: function (data) {
console.log(data);
}
});
});
var xhr = new XMLHttpRequest();
var url = 'https://developers.zomato.com/api/v2.1/search';
xhr.open('GET', url, false);
xhr.setRequestHeader('Accept', 'application/json');
xhr.setRequestHeader('user_key', 'XXXXXX');
xhr.send(null);
if (xhr.status == 200) {
console.log(xhr.responseText);
}
Error I'm getting:
OPTIONS https://developers.zomato.com/api/v2.1/search
XMLHttpRequest cannot load https://developers.zomato.com/api/v2.1/search. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access. The response had HTTP status code 501.
If somebody wants to reproduce you can get a free user-key here:
https://developers.zomato.com/api
There does not appear to be a work-around for this issue from a browser. The CORS specification requires a browser to preflight the request with the OPTIONS request if any custom headers are required. And, when it does the OPTIONS preflight, it does not include your custom headers because part of what the OPTIONS request is for is to find out what custom headers are allowed to be sent on the request. So, the server is not supposed to require custom headers on the OPTIONS request if it wants this to work from a browser.
So, if the server is requiring the custom headers to be on the OPTIONS request, then the server is just expecting something that will not happen from a browser.
See related answers that describe more about this here:
jQuery CORS Content-type OPTIONS
Cross Domain AJAX preflighting failing Origin check
How do you send a custom header in a cross-domain (CORS) XMLHttpRequest?
Using CORS for Cross-Domain Ajax Requests
And, another user with the same issue here:
Zomato api with angular
It appears the Zomato is not browser friendly, but requires access from a server where you don't have CORS restrictions.
FYI, the error coming back from Zomato is 501 which means NOT IMPLEMENTED for the OPTIONS command. So, it looks like it's not only that the key is not being sent with the OPTIONS command, but that Zomato does not support the OPTIONS command, but that is required for the use of custom headers on a cross-origin request from a browser.
You can't bypass Access-Control-Allow-Headers in preflight response.
However as mentioned by #Jaromanda X in comments, Zomato sends:
Access-Control-Allow-Headers:X-Zomato-API-Key
...meaning you can only send this non-standard header from browser. Also don't go too low-level in request definition when jQuery has pretty and prepared shorthands ...
TL;DR Working example:
$.ajax({
type: "GET", //it's a GET request API
headers: {
'X-Zomato-API-Key': 'YOUR_API_KEY' //only allowed non-standard header
},
url: 'https://developers.zomato.com/api/v2.1/dailymenu', //what do you want
dataType: 'json', //wanted response data type - let jQuery handle the rest...
data: {
//could be directly in URL, but this is more pretty, clear and easier to edit
res_id: 'YOUR_RESTAURANT_OR_PLACE_ID',
},
processData: true, //data is an object => tells jQuery to construct URL params from it
success: function(data) {
console.log(data); //what to do with response data on success
}
});
UPDATE Mar 21
After more investigation it looks like this is also showing a Play framework bug an XHR limitation on error status:
Play 2.2.1 SimpleResult 4xx Response Body Possible via CORS XHR? That, or the RESTfulness I seek is not possible with 401 codes.
Still an issue in both spaces since a 401 gets a 0 status code in Angular $http as below. So much for RESTfulness! All I want to do is provide a response body for 401 Unauthorized. From the W3C page on 4xx: "User agents SHOULD display any included entity to the user."
UPDATE Mar 20
Further investigation points to an issue within XMLHttpRequest itself, but please let me know if I am missing something below. I am spitting out the raw XHR object inside the xhr.onreadystatechange() callback as defined inside Angular's createHttpBackend():
When I log in with a known good email and password, everything works fine:
But the same XHR object for a 400 Bad Request (wrong password) has an empty response but more importantly status=0, which from Mozilla docs denotes the request was never sent (but I am seeing my API server get the request and do a DB lookup, as Postman works as above):
What gives? How does Postman get a response but XMLHttpRequest on latest Chrome and Firefox is confused?
I am sending a POST request using $http and getting conflicting responses in the browser (Chrome and FF), and Postman. Postman works fine and has the body, but it looks like angular is "cleaning" up some response codes to handle weirdness on Android browsers when templates are cached, but I can't pinpoint the spot in $httpBackend where the raw XHR is happening to intercept the response body--maybe that's because the XHR is blocking/canceling the response? Because security? I do not have any interceptors, either.
The "happy path" login works fine and I get matching 200 OK responses in the console/firebug, but 400 Bad Request doesn't have a response body.
CORS is configured on nginx (see http://enable-cors.org/server_nginx.html) and since the happy login success works the setup is functional.
My call:
var onLoginSuccess = function(data, status, headers, config){
console.log('[onLoginSuccess]')
console.log(data)
console.log(status)
console.log(headers)
console.log(config)
}
var onLoginError = function(data, status, headers, config){
console.log('[onLoginError]')
console.log(data)
console.log(status)
console.log(headers)
console.log(config)
}
var loginObj = {
'username': $scope.username,
'password': $scope.password,
'grant_type': 'password',
'client_id': 'web'
}
var doLogin = $http({
method: 'POST',
url: 'https://api/v1/token',
headers: {'Content-Type': 'application/x-www-form-urlencoded'},
transformRequest: function(obj) {
var str = [];
for(var p in obj) {
str.push(encodeURIComponent(p) + '=' + encodeURIComponent(obj[p]));
}
return str.join('&');
},
data: loginObj,
responseType: 'json'
})
doLogin.then(
onLoginSuccess,
onLoginError
)
Angular is modifying the error code so the browser and angular do not agree:
When I send the same request via Postman, the 400 Bad Request code is the same, but the body is also a json string, as expected.
Why is this not available via $http CORS inside the onLoginError() callback?
The problem I think is you are sending the POST body as JSON, rather it need to send as query param. Try this change
var loginObj = $.param({
'username': $scope.username,
'password': $scope.password,
'grant_type': 'password',
'client_id': 'web'
});
This will make your body as query params. Also don't forget to include jquery.js library
The issue ended up being with my api server code. My app was only sending Content-Type headers but I thought nginx would be able to serve up Allow-Origin headers and keep the app ignorant of any headers.
See Play 2.2.1 SimpleResult 4xx Response Body Possible via CORS XHR? for the answer. It's the Play Scala .withHeaders() part that fixed the issue via CORS.
Wonder if there's a way to have nginx handle all headers, maybe my proxy_pass section is not done right.
I have a basic AngularJS service setup like so:
app.factory('User', function($resource) {
return $resource('http://api.mysite.com/user/:action:id/:attr', {}, {
history: {
method: 'GET',
params: {
attr: 'history'
}
},
update: {
method: 'POST',
params: {
name: 'test'
}
}
});
});
and I use it like this:
User.history({id: 'testID'}, function(data) {
console.log('got history');
console.log(data);
});
User.update({id: 'me'}, function(data) {
console.log('updated');
console.log(data);
});
Problem one: User.update(), despite having the method set to POST, keeps sending OPTIONS as the request method.
Though Chrome Dev tools reports the request header Access-Control-Request-Method:POST is sent as well (Not sure if that means anything).
Problem two: I keep getting an error with CORS, despite having these headers set in the API code:
header('Access-Control-Allow-Origin: *');
header("Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS");
This problem only shows up though if making a non-GET request.
What's the proper way to be handling this? I've also looked into JSONP, but with this being a RESTful api, I'm not sure how to get around the problems with only GET support.
Your two problems are actually one problem. The OPTIONS request is part of the CORS process. For POST requests, the browser first sends an OPTIONS call, and the server responds if it is okay to execute it.
If the OPTIONS request fails, Angular / Chrome shows you the reason in the console. For example:
OPTIONS https://*** Request header field Content-Type is not allowed by Access-Control-Allow-Headers. angular.min.js:106
XMLHttpRequest cannot load https://***. Request header field Content-Type is not allowed by Access-Control-Allow-Headers.
You probably have to set Access-Control-Allow Headers on the server, too:
header('Access-Control-Allow-Headers: Content-Type, x-xsrf-token')
x-xrsf-token is for angular' to prevent CSRF. You may have to add more headers, depending on what you send from the client.
Here is a very good guide on CORS: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
In AngularJS to make CORS working you also have to overwrite default settings of the angular httpProvider:
var myApp = angular.module('myApp', [
'myAppApiService']);
myApp.config(['$httpProvider', function($httpProvider) {
$httpProvider.defaults.useXDomain = true;
delete $httpProvider.defaults.headers.common['X-Requested-With'];
}
]);
Just setting useXDomain to true is not enough. AJAX request are also
send with the X-Requested-With header, which indicate them as being
AJAX. Removing the header is necessary, so the server is not rejecting
the incoming request.
Note: Answer only works for older AngularJS version previous to 1.2. With 1.2 and above you don't have to do do anything to enable CORS.
Better to solve this problem at the server. On apache you can solve it like this in a .htaccess file. This is a source of pain for angular development and can be solved in angular as well but its probably not the best way to do it.
Header set Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"