Related
I am building a web API. I found whenever I use Chrome to POST, GET to my API, there is always an OPTIONS request sent before the real request, which is quite annoying. Currently, I get the server to ignore any OPTIONS requests. Now my question is what's good to send an OPTIONS request to double the server's load? Is there any way to completely stop the browser from sending OPTIONS requests?
edit 2018-09-13: added some precisions about this pre-flight request and how to avoid it at the end of this reponse.
OPTIONS requests are what we call pre-flight requests in Cross-origin resource sharing (CORS).
They are necessary when you're making requests across different origins in specific situations.
This pre-flight request is made by some browsers as a safety measure to ensure that the request being done is trusted by the server.
Meaning the server understands that the method, origin and headers being sent on the request are safe to act upon.
Your server should not ignore but handle these requests whenever you're attempting to do cross origin requests.
A good resource can be found here http://enable-cors.org/
A way to handle these to get comfortable is to ensure that for any path with OPTIONS method the server sends a response with this header
Access-Control-Allow-Origin: *
This will tell the browser that the server is willing to answer requests from any origin.
For more information on how to add CORS support to your server see the following flowchart
http://www.html5rocks.com/static/images/cors_server_flowchart.png
edit 2018-09-13
CORS OPTIONS request is triggered only in somes cases, as explained in MDN docs:
Some requests don’t trigger a CORS preflight. Those are called “simple requests” in this article, though the Fetch spec (which defines CORS) doesn’t use that term. A request that doesn’t trigger a CORS preflight—a so-called “simple request”—is one that meets all the following conditions:
The only allowed methods are:
GET
HEAD
POST
Apart from the headers set automatically by the user agent (for example, Connection, User-Agent, or any of the other headers with names defined in the Fetch spec as a “forbidden header name”), the only headers which are allowed to be manually set are those which the Fetch spec defines as being a “CORS-safelisted request-header”, which are:
Accept
Accept-Language
Content-Language
Content-Type (but note the additional requirements below)
DPR
Downlink
Save-Data
Viewport-Width
Width
The only allowed values for the Content-Type header are:
application/x-www-form-urlencoded
multipart/form-data
text/plain
No event listeners are registered on any XMLHttpRequestUpload object used in the request; these are accessed using the XMLHttpRequest.upload property.
No ReadableStream object is used in the request.
Have gone through this issue, below is my conclusion to this issue and my solution.
According to the CORS strategy (highly recommend you read about it) You can't just force the browser to stop sending OPTIONS request if it thinks it needs to.
There are two ways you can work around it:
Make sure your request is a "simple request"
Set Access-Control-Max-Age for the OPTIONS request
Simple request
A simple cross-site request is one that meets all the following conditions:
The only allowed methods are:
GET
HEAD
POST
Apart from the headers set automatically by the user agent (e.g. Connection, User-Agent, etc.), the only headers which are allowed to be manually set are:
Accept
Accept-Language
Content-Language
Content-Type
The only allowed values for the Content-Type header are:
application/x-www-form-urlencoded
multipart/form-data
text/plain
A simple request will not cause a pre-flight OPTIONS request.
Set a cache for the OPTIONS check
You can set a Access-Control-Max-Age for the OPTIONS request, so that it will not check the permission again until it is expired.
Access-Control-Max-Age gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request.
Limitation Noted
For Chrome, the maximum seconds for Access-Control-Max-Age is 600 which is 10 minutes, according to chrome source code
Access-Control-Max-Age only works for one resource every time, for example, GET requests with same URL path but different queries will be treated as different resources. So the request to the second resource will still trigger a preflight request.
Please refer this answer on the actual need for pre-flighted OPTIONS request: CORS - What is the motivation behind introducing preflight requests?
To disable the OPTIONS request, below conditions must be satisfied for ajax request:
Request does not set custom HTTP headers like 'application/xml' or 'application/json' etc
The request method has to be one of GET, HEAD or POST. If POST, content type should be one of application/x-www-form-urlencoded, multipart/form-data, or text/plain
Reference:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
When you have the debug console open and the Disable Cache option turned on, preflight requests will always be sent (i.e. before each and every request). if you don't disable the cache, a pre-flight request will be sent only once (per server)
Yes it's possible to avoid options request. Options request is a preflight request when you send (post) any data to another domain. It's a browser security issue. But we can use another technology: iframe transport layer. I strongly recommend you forget about any CORS configuration and use readymade solution and it will work anywhere.
Take a look here:
https://github.com/jpillora/xdomain
And working example:
http://jpillora.com/xdomain/
For a developer who understands the reason it exists but needs to access an API that doesn't handle OPTIONS calls without auth, I need a temporary answer so I can develop locally until the API owner adds proper SPA CORS support or I get a proxy API up and running.
I found you can disable CORS in Safari and Chrome on a Mac.
Disable same origin policy in Chrome
Chrome: Quit Chrome, open an terminal and paste this command: open /Applications/Google\ Chrome.app --args --disable-web-security --user-data-dir
Safari: Disabling same-origin policy in Safari
If you want to disable the same-origin policy on Safari (I have 9.1.1), then you only need to enable the developer menu, and select "Disable Cross-Origin Restrictions" from the develop menu.
As mentioned in previous posts already, OPTIONS requests are there for a reason. If you have an issue with large response times from your server (e.g. overseas connection) you can also have your browser cache the preflight requests.
Have your server reply with the Access-Control-Max-Age header and for requests that go to the same endpoint the preflight request will have been cached and not occur anymore.
I have solved this problem like.
if($_SERVER['REQUEST_METHOD'] == 'OPTIONS' && ENV == 'devel') {
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Headers: X-Requested-With');
header("HTTP/1.1 200 OK");
die();
}
It is only for development. With this I am waiting 9ms and 500ms and not 8s and 500ms. I can do that because production JS app will be on the same machine as production so there will be no OPTIONS but development is my local.
You can't but you could avoid CORS using JSONP.
After spending a whole day and a half trying to work through a similar problem I found it had to do with IIS.
My Web API project was set up as follows:
// WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
var cors = new EnableCorsAttribute("*", "*", "*");
config.EnableCors(cors);
//...
}
I did not have CORS specific config options in the web.config > system.webServer node like I have seen in so many posts
No CORS specific code in the global.asax or in the controller as a decorator
The problem was the app pool settings.
The managed pipeline mode was set to classic (changed it to integrated) and the Identity was set to Network Service (changed it to ApplicationPoolIdentity)
Changing those settings (and refreshing the app pool) fixed it for me.
OPTIONS request is a feature of web browsers, so it's not easy to disable it. But I found a way to redirect it away with proxy. It's useful in case that the service endpoint just cannot handle CORS/OPTIONS yet, maybe still under development, or mal-configured.
Steps:
Setup a reverse proxy for such requests with tools of choice (nginx, YARP, ...)
Create an endpoint just to handle the OPTIONS request. It might be easier to create a normal empty endpoint, and make sure it handles CORS well.
Configure two sets of rules for the proxy. One is to route all OPTIONS requests to the dummy endpoint above. Another to route all other requests to actual endpoint in question.
Update the web site to use proxy instead.
Basically this approach is to cheat browser that OPTIONS request works. Considering CORS is not to enhance security, but to relax the same-origin policy, I hope this trick could work for a while. :)
you can also use a API Manager (like Open Sources Gravitee.io) to prevent CORS issues between frontend app and backend services by manipulating headers in preflight.
Header used in response to a preflight request to indicate which HTTP headers can be used when making the actual request :
content-type
access-control-allow-header
authorization
x-requested-with
and specify the "allow-origin" = localhost:4200 for example
One solution I have used in the past - lets say your site is on mydomain.com, and you need to make an ajax request to foreigndomain.com
Configure an IIS rewrite from your domain to the foreign domain - e.g.
<rewrite>
<rules>
<rule name="ForeignRewrite" stopProcessing="true">
<match url="^api/v1/(.*)$" />
<action type="Rewrite" url="https://foreigndomain.com/{R:1}" />
</rule>
</rules>
</rewrite>
on your mydomain.com site - you can then make a same origin request, and there's no need for any options request :)
It can be solved in case of use of a proxy that intercept the request and write the appropriate headers.
In the particular case of Varnish these would be the rules:
if (req.http.host == "CUSTOM_URL" ) {
set resp.http.Access-Control-Allow-Origin = "*";
if (req.method == "OPTIONS") {
set resp.http.Access-Control-Max-Age = "1728000";
set resp.http.Access-Control-Allow-Methods = "GET, POST, PUT, DELETE, PATCH, OPTIONS";
set resp.http.Access-Control-Allow-Headers = "Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since";
set resp.http.Content-Length = "0";
set resp.http.Content-Type = "text/plain charset=UTF-8";
set resp.status = 204;
}
}
What worked for me was to import "github.com/gorilla/handlers" and then use it this way:
router := mux.NewRouter()
router.HandleFunc("/config", getConfig).Methods("GET")
router.HandleFunc("/config/emcServer", createEmcServers).Methods("POST")
headersOk := handlers.AllowedHeaders([]string{"X-Requested-With", "Content-Type"})
originsOk := handlers.AllowedOrigins([]string{"*"})
methodsOk := handlers.AllowedMethods([]string{"GET", "HEAD", "POST", "PUT", "OPTIONS"})
log.Fatal(http.ListenAndServe(":" + webServicePort, handlers.CORS(originsOk, headersOk, methodsOk)(router)))
As soon as I executed an Ajax POST request and attaching JSON data to it, Chrome would always add the Content-Type header which was not in my previous AllowedHeaders config.
I'm using JQuery:
$('#myDiv').load('myApp/url',function(){ });
and it's giving No 'Access-Control-Allow-Origin' header is present on the requested resource By chrome, and firefox so far , any straight forward answer on how to fix this . I don't have control over server to make any configurations and I'm using PHP
This is a CORS issue (Cross Origin Resource Sharing), you are trying to request content via ajax from two different domains. Unless the domain from where you want to grab the data has properly set the CORS headers, browsers will cancel the request right away.
This occurs due to the communication between two different domains. The domain that will server your data, should have some headers set, this headers act as permissions, they tell which domains are allowed to ask for data from it, and which verbs/methods are allowed.
You can read more about this here and here
No, there won't be a straight forward answer to this because it will depend entirely on your system/server setup, and what you have access to. Here's what you need to know.
In the beginning -- AJAX requests had a very strict "same origin" policy. This meant if you made an ajax request FROM a website with the domain example.com, you could only make a request to a URL that was on example.com.
In more recent years browsers have loosened up on this. If the server that you're making a request to has an Access-Control-Allow-Origin header, and that header includes the URL/domain of the server you're making the request from, then the request will be allowed. Similar question/answer here.
So, how you set this header depends on the server you're making a request to. If you have control over this server, start your Googling there.
If you don't have control over this server, you need to make a request to php page on your server, and this PHP page should make a curl request to the server that had the information you don't. A curl request, happening outside the browser, isn't subject to the same cross domain issues.
The easy way is to do this by hand:
var script = document.createElement('script');
script.src = uri;
script.id = 'scriptid';
document.head.appendChild(script);
It may be some browser compatibility issues, but you get the power of CORS with no 'Access-Control-Allow-Origin' error
Json issues with javascript and jquery.
Trying to load some JSON using javascript.
I have it working using:
See it here: http://jsfiddle.net/5pjha/789/
var url = "http://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&sensor=true";
$.getJSON(url, function (json) {
alert(JSON.stringify(json.results));
});
But it dosnt work on the following urls, why is this?
https://poloniex.com/public?command=return24hVolume
https://bittrex.com/api/v1/public/getmarkets
https://api.mintpal.com/v1/market/summary/
Are the following urls not correct JSON ?
Thanks
The google's api set the Access-Control-Allow-Origin header to *, so you could access it by cross domain.
While other urls you provided do not, so you will got an error like below:
XMLHttpRequest cannot load https://api.mintpal.com/v1/market/summary/.
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://fiddle.jshell.net' is therefore not allowed
access.
I believe the issue is down to whether or not the servers you are requesting your JSON from have cross-origin resource sharing (CORS) enabled.
you can see in the headers from the google service that they set Access-Control-Allow-Origin:* This is not the case for teh other URL's you list.
To get around this you will need some form of proxy so that you can request from a server either on the same domain or a server that enables CORS.
For ajax request to any server, You need to define Access-Control-Allow-Origin header for client. which is absent in given. You need to define origin of XMLHttp request in server who can request.
For more info refer this link
I'm trying to send an AJAX request from a secure page, but the XMLHttpRequest object doesn't properly resolve the protocol portion of the URL. This behavior is identical in Safari, Chrome, and Canary.
Here's my JavaScript:
function sendGETRequest(url, params, callback) {
"use strict";
var req = new XMLHttpRequest();
req.onreadystatechange = function () {
if (req.readyState === 4) {
if (req.status !== 200) {
callback({ajaxError: true, status: req.status});
} else {
callback(req);
}
}
};
req.open("GET", url + "?" + params, true);
req.setRequestHeader("X-Requested-With", "XMLHttpRequest");
req.send();
}
Here are some different URLs passed to sendGETRequest(), along with their results:
url = "ajax/";
GET https://mydomain/mypage/ajax/?params 404 (NOT FOUND)
The above is the expected behavior: the relative url is correctly resolved with protocol intact.
url = "/ajax/";
The page at https://mydomain/mypage/ displayed insecure content from http://mydomain/ajax/?params.
Here, the realtive url is correctly appended to the domain root, but with the wrong protocol.
url = "https://mydomain/ajax/";
The page at https://mydomain/mypage/ displayed insecure content from http://mydomain/ajax/?params.
Here, the protocol is just ignored.
To be clear, I'm not trying to work around the same origin policy; I want to send an AJAX request from a secure page to a resource with the same (secure) origin. How can I accomplish this simple task?
There is a conversation here about this topic: http://bytes.com/topic/javascript/answers/459071-ajax-https
One of the last posts states "Just to be absolutely unambiguous; XML HTTP requests work over https
exactly as they do over http. If they did not our QA department would
have said something by now as they test over https almost exclusively"
Perhaps the server is not using Https (ssl) at the point where the request is being made: mydomain/ajax/.
This has nothing to do with HTTP and HTTPS. As you mentioned in a comment, the request is never being sent due to same-origin policy. How can the request be using the wrong policy if the request is never sent? What is confusing you is that whatever program/add-on/tool/etc that is generating the error message is showing "HTTP" instead of "HTTPS". The request IS and ALWAYS respects HTTPS when HTTPS is set.
Your real issue is quite simply that you are violating cross-origin policy. See this:
https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs
You cannot go UP the directory tree, only down. In the first example, you are requesting a subfolder. That's fine. In the second and third examples, you are requesting a page from a parent directory (ie, instead of https://mydomain/mypage/ajax/ you are asking for https://mydomain/ajax/. You cannot make a request up a directory tree like that.
Either move your index page up to the root of the domain, or change the same-origin policy header being sent on the files, or make a sub directory on the server handle the request (you can use something like PHP's include to just include the parent file).
This is a bug in WebKit. It's been fixed in Safari 5 for Lion but not Snow Leopard, and it's been fixed in Chrome but not Canary,... helluva a bug.
This question already has answers here:
XMLHttpRequest cannot load XXX No 'Access-Control-Allow-Origin' header
(11 answers)
Closed 6 years ago.
I am seeing the following error:
Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin
with this code:
var http = new getXMLHttpRequestObject();
var url = "http://gdata.youtube.com/action/GetUploadToken";
var sendXML = '<?xml version="1.0"?><entry xmlns="http://www.w3.org/2005/Atom"'+
'xmlns:media="http://search.yahoo.com/mrss/'+
'xmlns:yt="http://gdata.youtube.com/schemas/2007">'+
'<media:group><media:title type="plain">My First API</media:title>'+
'<media:description type="plain">First API</media:description>'+
'<media:category scheme="http://gdata.youtube.com/schemas/2007/categories.cat">People</media:category>'+
'<media:keywords>first, api</media:keywords></media:group></entry>';
http.open("POST", url, true);
http.setRequestHeader("Authorization", "AuthSub token=" + AccessToken);
http.setRequestHeader("X-GData-Key", "key="+ dev_key);
http.setRequestHeader("Content-Type", "application/atom+xml; charset=UTF-8");
http.onreadystatechange = function() {
if(http.readyState == 4) {
alert(http.responseXML);
}
}
http.send(sendXML);
What can cause this, and how do I solve it?
Javascript is limited when making ajax requests outside of the current domain.
Ex 1: your domain is example.com and you want to make a request to test.com => you cannot.
Ex 2: your domain is example.com and you want to make a request to inner.example.com => you cannot.
Ex 3: your domain is example.com:80 and you want to make a request to example.com:81 => you cannot
EX 4: your domain is example.com and you want to make a request to example.com => you can.
Javascript is limited by the "same origin policy" for security reasons so that a malicious script cannot contact a remote server and send sensitive data.
jsonp is a different way to use javascript. You make a request and results are encapsulated into a callback function which is run in the client. It's the same as linking a new script tag into the head part of your html (you know that you can load scripts from different domains than yours here).
However, to use jsonp the server must be configured properly. If this is not the case you cannot use jsonp and you MUST rely on a server side proxy (PHP, ASP, etc.). There are plenty of guides related to this topic, just google it!
XMLHttpRequest will not let you reach localhost:8080 because of the "same origin policy".
You can allow requests from modern browsers by adding a header to your response on localhost:8080:
Access-Control-Allow-Origin: *
You can do so by adding directives to your HTTP server or adding headers via server-side code (PHP, Ruby, ...).
Read more on Cross-Origin ajax requests on https://developer.mozilla.org/en/http_access_control
If you are using Chrome, a simple workaround (only for development purposes) is to use option --disable-web-security.
Add a global.asax in your solution.
Add
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
in
protected void Application_BeginRequest(object sender, EventArgs e)
{
}
If your using apache, this works: put this in/create a .htaccess file in your public root, and add any other file extensions you might need.
<FilesMatch "\.(ttf|otf|eot|woff|jpg|png|jpeg|gif|js|json|html|css)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
For local development you can use a tool for modifying the HTTP response headers. For example Charles is able to do this by the included rewrite tool: Rewrite Tool
Just add a new rule for the target domain/location with:
Type: Add Header
Where: Response
Replace
Name: Access-Control-Allow-Origin
Value: *
Replace All
Here, we need to do two things for Apache Http
1) In httpd.config file, uncomment this file
LoadModule headers_module modules/mod_headers.so
2) Add this line at the bottom.
Header set Access-Control-Allow-Origin "*"
if you re using google chrome as a browser you can add CORS extension, and activate it , it will solve the hole problem without having to change anything in your code
Unrelated to this particular question, but for anyone in this situation using jQuery...This error is also caused if you try to make a JSONP request using jQuery and omit the magic callback parameter: callback=?
If you are from a java background one possible solution could be to make a servlet which calls the Web-services for your javascript. something like the below code in the GET(Your-choice) method...
JsonElement jelement;
JsonArray jarray;
try {
URL url = new URL("http://rest."YOUR URL"#ba0482");
URLConnection connection = url.openConnection();
connection.setDoInput(true);
InputStream inStream = connection.getInputStream();
BufferedReader input = new BufferedReader(new InputStreamReader(inStream));
jelement = new JsonParser().parse(input);
jarray = jelement.getAsJsonArray();
response.setContentType("application/json");
PrintWriter out = response.getWriter();
out.print(jarray);
out.flush();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
Now in the javascript simply specify the url as the servlet name!!
I run into the same error message, when using ajax to access a php page (javascript and php file are both located on same server).
The reason was that I specified the IP address as the domain in my JavaScript. This made the Browser believe that the call to the php file is on another server.
So an easy solution to get rid off this error message.
a) verify javascript and php file are on the same server
b) make sure the url (in particular the domain) in your JavaScript (e.g. http://www.smartana.co.uk/myJavaScript.js) ajax reflects your server url (e.g. http://www.smartana.co.uk/myServer.php).