For our APP we have a Web App and a API service, On A certain event the Web app polls the api service for the state of the event using Javascript. Both the apps run on a separate HTTPS sub domain and with a self signed certificate(as it is still in alpha). The problem occurs that the polling is aborted because the https api connection is untrusted. Is it some way for the Javascript request to override the untrusted certificate issue?
Is it some way for the Javascript request to override the untrusted certificate issue?
No, it's because of the same origin policy restriction.
In your case I suppose that you have a page hosted on https://foo.bar.com and you are trying to send an AJAX request to https://baz.bar.com which is not allowed.
You may take a look at the following guide which covers the different possibilities to circumvent this restriction. They range from JSONP, server side script bridges, Flash proxies, screen scraping with YQL, ...
No, you have to add the self-signed certificate to your machine/browser's trusted certificate store.
You also have cross-domain origin issues (the different subdomain), which is separate from any certificate issues. If you're already using JSONP, you're fine; but if you're trying to make an XHR request to a different domain, it's not going to work.
Related
So I deployed all of my React apps that are using an API. I am having problems sending this api and something block them and so my apps aren't working.
Note: all of my requests are cors so there is no problem with them.
github block my request
and this is link to the project in picture news-blog
The problem is that you're trying to fetch non-secure (http) content from a secure (https) site, which violates the site's Content-Security-Policy (CSP). This is an insecure behavior as far as modern browsers are concerned.
From MDN:
The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS).
The right way of solving this would be to load the data from a secure source. For example, instead of fetching from http://newsapi.org/v2/everything, try https://newsapi.org/v2/everything (note the difference between http and https).
Situation:
I have a production web server, let's say https://example.com, configured with CORS with limited set of allowed origins. The set does NOT include localhost origins.
On localhost, developers develop a page/module/whatever that needs to call the production web server via AJAX (even during development). To do that, they run Chrome with CLI arguments --disable-web-security --user-data-dir=chromeNoCors so that Chrome would send AJAX without Origin header.
The problem is that only GET requests are sent without the header. POST requests still contain the header, therefore the production server compares the header value (http://localhost:5678) with allowed set of origins and forbids access to requested resource.
Question:
Is it possible to somehow prevent sending of Origin HTTP header altogether?
I'm aware that there's a workaround to solve this situation by allowing "localhost" (or some specific host that developers will have to add to their /etc/hosts) to the set of allowed origins on production server but I'd like not to do this if possible.
if you guys use chrome try this extension
https://chrome.google.com/webstore/detail/requestly-redirect-url-mo/mdnleldcmiljblolnjhpnblkcekpdkpa
you can modify requests on the fly,even headers
I recommend that you setup a simple "proxy server" (short node.js or python script would suffice). Have this server forward all requests to your remote API server but delete the information about the origin in headers. This is a matter of simple regular expression.
This is simple solution that will be portable to different servers. On AJAX side, all you need is to change the hostname to localhost or IP of your testing proxy server.
I have a NodeJS server running on my machine, and I am trying to access it with ajax from a website running on the same machine. I have getting a cross domain error though:
XMLHttpRequest cannot load http://localhost:3000/games. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access.
I have access a different api on this machine, running with php, which the address is
http://localhost/games.
My thinking is that because the nodejs server is running on a different port to apache that is causing the cross domain issue?
Any insight would be great, im new to api development and not sure where to go from here.
It has been suggested to me that I should try use JSONP, but im not sure if this is technically needed, since the api is running on the same machine?
An origin is defined as a combination of URI scheme, hostname, and port number so you're indeed breaking the same origin policy performing a XMLHttpRequest from http://localhost to http://localhost:3000
I'm not very familiar with nodejs but I see five options:
Obviously the easiest thing would be run everything on the same port, not sure if this is possible or not on your scenario.
Use JSONP (only valid for GET requests)
Implement CORS headers (it has some compatibilities issues with IE <= 9 + other corner case anomalies)
Implement a proxy to always communicate to http://localhost from client. Let the proxy deal with http://localhost:3000 and return response to client.
Use an alternative to perform cross domain request as XDomain
Since you need to be able to send POST requests, your only options are:
Implement CORS
Reverse Proxy
php proxy (or whatever language you are using for serving html pages)
The easiest would be to implement CORS if you are using express. Most of the work is done for you, all you would need to do is include the cors module and attach it as middleware.
Reverse proxy is the next solution to look at. What it does is it takes all requests to a given domain or domain/folder and reroutes them to the specified domain, in this case your node server running on a different port. For example, you would route all requests to http://localhost/api to http://localhost:3000. Research Reverse Proxy for the webserver you are using.
The third solution would be to have the webserver serving html also send requests to the node server. I consider this to be a bit too hacky for my tastes because the above two solutions are easy to implement and don't add additional code to the html webserver. However, if you didn't own the target webserver, this would be the only option if the target webserver didn't support CORS.
I am designing a website that uses JavaScript Ajax XHR calls to retrieve dynamic data.
I have two C++ based applications that serve data on their own ports, and I have control of the ports that they use.
Dynamic Data is requested with HTTP 1.1 requests and data is returned with an HTTP 1.1 header, and I have control of the header data. Effectively, I have a custom HTTP server embedded in my dynamic data applications, so I have full control of both ends of the conversation.
If I choose two arbitrary ports to serve the dynamic data on, will the browser-based user have to open those ports on their firewall to allow the request from my web page?
For example, the web page would be served as www.mydomain.com/default.aspx, and within it, it would have Ajax XHR calls to make connections to www.mydomain.com:8080 and www.mydomain.com:8081 (or whatever port numbers are chosen).
Am I going to be blocked by the same origin policy?
Could I get away with using ports that are often open on firewalls, but not actively being served on my server?
What is the best way to work around this so that the user does not have to make firewall changes and does not get a cross domain warning? I'm hoping not to use iFrames if possible.
This topic may have been asked before, I have searched thoroughly but have not found anything that matches.
Wikipedia says you have to keep the same scheme, host and port but notes that some unnamed browsers do not enforce the port.
http://en.wikipedia.org/wiki/Same_origin_policy
The scheme is like HTTP:
The host name is like my.yahoo.com but there are some possiblilites to access any ???.yahoo.com in some browsers.
Port is pretty clear but notice that HTTP and HTTPS use different ports as the default.
This page is interesting:
http://www.w3.org/Security/wiki/Same_Origin_Policy
We have a "widget" that runs on 3rd party websites, that is, anyone who signs up with our service and embeds the JavaScript.
At the moment we use JSONP for all communication. We can securely sign people in and create accounts via the use of an iFrame and some magic with detecting load events on it. (Essentially, we wait until the iFrames source is pointing back to the clients domain before reading a success value out of the title of it).
Because we're running on JSONP, we can use the browsers HTTP cookies to detect if the user is logged in.
However, we're in the process of transitioning our system to run realtime and over web sockets. We will still have the same method for authentication but we won't necessarily be making other calls using JSONP. Instead those calls will occur over websockets (using the library Faye)
How can I secure this? The potential security holes is if someone copies the JavaScript off an existing site, alters it, then gets people to visit their site instead. I think this defeats my original idea of sending back a secure token on login as the malicious JavaScript would be able to read it then use it perform authenticated actions.
Am I better off keeping my secure actions running over regular JSONP and my updates over WebSockets?
Websocket connections receive cookies only during the opening handshake. The only site that can access your websocket connection is the one that opened it, so if you're opening your connection after authentication then I presume your security will be comparable to your current JSONP implementation.
That is not to say that your JSONP implementation is secure. I don't know that it isn't, but are you checking the referrers for your JSONP requests to ensure they're really coming from the same 3rd-party site that logged in? If not, you already have a security issue from other sites embedding your javascript.
In any case, the 3rd-party having an XSS vulnerability would also be a very big problem, but presumably you know that already.
Whether you are sent cookies during opening WebSocket handshake by browser (and if so, what cookies) is not specified by the WS spec. It's left up to browser vendors.
A WS connection can be opened to any site, not only the site originally serving the JS doing the connection. However, browsers MUST set the "Origin" HTTP header in the WS opening handshake to the one originally serving the JS. The server is then free to accept or deny the connection.
You could i.e. generate a random string in JS, store that client side, and let that plus the client IP take part in computing an auth token for WS ..