I'm new to xmlhttprequest, and I need a little help with cross origin requests.
I make a xmlhttprequest from web service, everything is going nice and smooth from my local host.
but when I'm running from the server I get cross-origin exception (that's because the origin (site) and the web service are not located at the same location)...
I've tried to set the Access-Control-Allow-Origin to '*' threw req.setRequestHeader function without success.
P.s I'm writing in javascript.
I'll be glad for any help.
Well the answer is:
We can't locate our client files in one server and make a httprequest to another,
for security reasons the browser blocks the request...
so the options are:
To locate both client & server files in on the same server.
There couple ways to manipulate the server which include changing scripts in the server files (really not recomended for beginners... )
Enjoy
Related
I have developed a node js application which works fine as long as use http. Now I need to upgrade the code too be able to work ssl and I am having problems to load the socket.io-client/socket.io.js file. (The rest is working fine. I installed the certificates and the server works well)
Firefox fails with the following message: Blocked loading mixed active content "http://"url"/socket.io/?EIO=3&transport=polling&t=NX-uS5E". which is weird because the link states a http request.
Chrome fails with this message: socket.io.js:3511 Mixed Content: The page at 'https://"url"?' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://"url"/socket.io/?EIO=3&transport=polling&t=NX-s_OB'. This request has been blocked; the content must be served over HTTPS.
It seems that socket.io-client is trying to load a resource using http instead of https. Is that possible?
How can I correct this? Any idea?
I have been searching the web for two days noow and I have not come to any indication of someone else having this issue
Ok, after letting it go for the evening and having a good rest I checked my whole code again and found the error!
I had one obfuscated code line where I was using a http request instead of a https one. I had to correct this on both, the server and the client side.
I also had to include the port number on each of the calls and force the socket on the client side to use polling instead of websockets by adding the option "transports: ['polling']"
I have a project, It's a web application that requires Windows Authentication.
I've setup an Active Directory at home using my NAS virtualization. Then I've created a VMWare Server for IIS which is a member of that domain on my desktop which I also use for development. I've created the Web API and installed it into that VMWare server. When I call a routine directly, it works and return results but when I use the Web API routine from my javascript web application I keep on getting 401 error. I then put the code on the IIS server and the web application works.
I've seen a lot of solutions like changing the sequence of the Provider in IIS Authentication. Added Everyone read/write permission on the folders. I've also added entry on the web.config. But none of them work.
*****Update as per request on the comment *****
Below is when I run directly from Web API
Calling the Web API from Javascript
Here's the error I'm getting
Just FYI, I tried running the web api from Visual Studio on the same machine but also with 401 error
Is there anything I could add to AD to make my development machine as trusted?
********************A new issue after the code change **********
****************Another Update******
This is definitely weird, so I installed Fiddler 4 to see what's going on. But still no luck.
Then I made changes on the IIS HTTP Response Header
The weird thing is when I run Fiddler the error is gone but when I close it it comes back.
There are two things going on here:
A 401 response is a normal first step to Windows Authentication. The client is then expected to resend the request with credentials. AJAX requests don't do this automatically unless you tell it to.
To tell it to send credentials in a cross-domain request (more on that later), you need to set the withCredentials option when you make the request in JavaScript.
With jQuery, that looks like this:
$.ajax({
url: url,
xhrFields: {
withCredentials: true
}
}).then(callback);
These problems pop up when the URL in the address bar of the browser is different than the URL of the API you are trying to connect to in the JavaScript. Browsers are very picky about when this is allowed. These are called "cross-domain requests", or "Cross-Origin Resource Sharing" (CORS).
It looks at the protocol, domain name and port. So if the website is http://localhost:8000, and it's making an AJAX request to http://localhost:8001, that is still considered a cross-domain request.
When a cross-domain AJAX request is made, the browser first sends an OPTIONS request to the URL, which contains the URL of the website that's making the request (e.g. http://localhost:8000). The API is expected to return a response with an Access-Control-Allow-Origin header that says whether the website making the request is allowed to.
If you are not planning on sending credentials, then the Access-Control-Allow-Origin header can be *, meaning that the API allows anyone to call it.
However, if you need to send credentials, like you do, you cannot use *. The Access-Control-Allow-Origin header must specifically contain the domain (and port) of your webpage, and the Access-Control-Allow-Credentials must be set to true. For example:
Access-Control-Allow-Origin: http://localhost:8000
Access-Control-Allow-Credentials: true
It's a bit of a pain in the butt, yes. But it's necessary for security.
You can read more about CORS here: Cross-Origin Resource Sharing (CORS)
I have a background task in a Chrome Extension that performs some polling/checking. In error cases, I want to retry the check using a different CDN server to verify if it's a site-wide problem or just a CDN node affected. The challenge is how to control to which CDN node to send to.
e.g. let's say I'm checking www.company.com and typically that will be served by server21.cdn.co
Now if that fails I want to check server5.cdn.co and server10.cdn2.co for the same content to see if there's a correlation.
These checks are done using XMLHttpRequest but I can't find a way to specify which host/proxy to use per-request.
I wouldn't want to "hijack" the entire browser's proxy server settings because it would cause all other pages/tabs to fail.
If it's load-balancing performed on the DNS level (which is most probable), you can't affect which server you actually contact at all.
To clarify, this can't be done because XMLHTTPRequest forbids overriding the Host header in requests. See https://security.stackexchange.com/questions/46702/how-can-i-control-the-content-of-the-http-host-header-in-requests-issued-from-my/ for an explanation of why.
Conceptually/technically it's easy to do if it weren't for this security issue. For example with curl:
curl --verbose --header 'Host: www.example.com' 'http://10.1.1.36/the_url_to_test'
But as mentioned in the question, we're stuck inside a Chrome extension so curl is not an option!
I'm working on a chrome app and finally got to the point of issuing a PUT to the node.js server. My GET logic is working fine. My PUT however gets hijacked into a OPTIONS request. My requests are made to
http://localhost:4000/whatever
I read about the OPTIONS pass asking permission to do the PUT. I was under the impression that BROWSERS issue OPTIONS when CORS is requested, but didn't realize that a chrome app would also do this for me.
Is the app doing this because I didn't and I'm supposed to, or is this SOP that chrome will issue the OPTIONS request and I just issue my PUT that triggers it?
My PUT never makes it to the server. I've tried issuing my own OPTIONS just ahead of my PUT but so far nothing is working. The OPTIONS request makes it to the server (the default one or mine), but that's the end of the conversation.
At the server, all I'm doing to satisfy the OPTIONS request is as follows:
case 'OPTIONS':
res.writeHead(200, {'Access-Control-Allow-Methods': 'OPTIONS, TRACE, GET, HEAD, POST, PUT',
'Access-Control-Allow-Origin': "*"});
break;
When I try issuing my own OPTIONS & PUT requests, I'm doing them with separate XMLHttpRequest objects. I don't see where the permission hand off from OPTIONS to PUT is made.
This is called "preflighting", and browsers MUST preflight cross-origin requests if they fit specific criteria. For example, if the request method is anything other than GET or POST, the browser must preflight the request. You will need to handle these OPTIONS (preflight) requests properly in your server.
Presumably, your page is hosted on a port other than 4000, and the call to port 4000 is then considered cross-origin (in all browsers other than IE). Don't issue the OPTIONS request yourself. Chrome will then preflight your request. Your server must respond appropriately. The browser will handle the response to this OPTIONS request for you, and then send along the PUT as expected if the OPTIONS request was handled properly by your server.
There is an excellent article on Mozilla Developer Network that covers all things CORS. If you plan on working in any cross-origin environment, you should read this article. It will provide you with most of the knowledge necessary to understand the concepts required to properly deal with this type of an environment.
What is a cross-domain error?
It happens when Javascript (most of the time) try to access something which it shouldn't.
Such as if you try to read another domain's cookie, that won't work. If you try to do XMLHTTP request to another domain or protocol (HTTP > HTTPS) that won't work. Because if you can do that you can hijack, steal your visitors session in other websites.
It's security feature and now it's a standard in all browser.
As I understand it, client-side tools such as Silverlight (and maybe Flash/Javascript) throw a cross-domain error when you attempt to make a connection to a server that is normally only allowed when it is made to the same domain that the page was served from (some origin policy).
A cross-domain error may be thrown when, for example, you are viewing a page on your test server when it is trying to call your live server, or when you are viewing a test page as a local file using a file:// protocol.
Try ensuring that the domain you are testing on is the same as that which the site was designed to be on. Note that Flash has the crossdomain.xml feature which specifically allow you to do cross-domain requests. Javascript also has ways to get around same origin policy, but you should be aware of the implications of what you're doing.