I have a webpage with a master script that connects, via AJAX, to a remote server and downloads unsecure JS scripts (let's call them slave scripts), to be executed lately on the client. I would like to limit the Internet access slave scripts have; e.g. they can communicate just with the remote server.
Do you have any idea of how can I achieve this?
Thanks,
Laurențiu Dascălu
You can't.
JavaScript AJAX calls will have access to whatever the browser has access to.
Your best bet would be attempt to create a third JavaScript component to proxy the slave script calls through. That component would be responsible for ensuring that the slave scripts weren't calling any URLs that they shouldn't be.
The downside, of course, is that anybody can download and modify all of your scripts anyway...which means that any proxy would be easy to overcome.
Use Caja. It can convert untrusted Javascript into safe Javascript which can only access specific resources as defined by you.
Run the scripts in an iframe hosted on a different domain, and the browser same-origin security policy should make it more secure.
Related
Not really trying to do this, moreover I am ultimately trying to understand the structure of third party JS scripts. Can I rename the GA JS so that if someone who is using NoScript or some similar extension, the name can be changed to a domain similar name, and not managed by the Google script?
If so, why don't people do this and rename it something by their domain?
If not, is their a way to make a script that passes the necessary information to a third party JS so that you can achieve your own JS scripts on the page, and have ultimate control over the experience (either the users allos all of the scripts associated with the page, or none), ultimately providing another layer of abstraction?
For some scripts, yes, if you're willing to effectively maintain a branch of someone else's internal code.
But if the script
creates an <iframe> and loads content into it from domain D,
that <iframe> communicates with a web service in domain D via XHR,
that web service requires cookies that are set on domain D
then no, you can't run it on your own domain because that <iframe> needs to be on the same-origin as the web service and any domain you host it on is not in that origin.
I need to embed WebView in my application, which has to pull some data via AJAX from multiple remote servers. Unfortunetely due to ajax sandbox, connections to foreign servers are blocked. How can I disable it, as the js code I'm running is trusted?
There's a simple workaround to allow connections to single server. It's as simple as using loadDataWithBaseUrl and passing the top level url as the first parameter. But what to do, when js should be able to access multiple different domains?
Thanks
Are the pages loaded into the webview local? i.e, Are they loaded from the local file system like: file://yourpage.html or are they remote pages?
Webpages loaded locally are not affected by the cross-domain ajax restrictions so you can load whatever you like.
If they're remote pages then i'm not sure how you're going to get around it, perhaps setup your own webservice on the same domain as where the pages are served from which simply fetches the data from the remote services and spits it back
I am writing an HTML5 application that is gathering data from a few different sources using JSONP. Anything I'm doing with a GET works perfectly. I'm now trying to POST data, and I've run into an interesting snag. I need to POST data from my application to another, where my application is running from a local machine. I am trying to write a cross-platform capable mobile application (think Pulse/Flipboard), so the code will always be running from a local source. My thought process was as follows:
Use JSONP - JSONP does not allow for posting, it just doesn't work that way (Post data to JsonP)
Rely on CORS - Since the request is coming from a local source using file://, the origin header is null. This causes the request to fail (XmlHttpRequest error: Origin null is not allowed by Access-Control-Allow-Origin)
Use another server to bounce the request off of - this would be expensive
All of the browsers I'm targeting are webkit based (iPad, Playbook, Android), so I'm wondering if there are any creaks in the same origin policy code that I can sneak through? Maybe something using iframe or postMessage?
As it would turn out, the easiest way to do this is to post to the target url inside of an iframe. Same origin policy on most browsers allows you to perform an HTTP POST from one domain to another unrelated domain. I solved the problem by adding an iframe to my page, initially set to a local bootstrapping page. Since that page was loaded from the same domain, I am able to control it via script. I used that to post the form to my target site, and polled the results to determine if my call was successful. It's not elegant, but it works.
This Javascript library can almost certainly help you:
http://easyxdm.net/
easyXDM is a Javascript library that
enables you as a developer to easily
work around the limitation set in
place by the Same Origin Policy, in
turn making it easy to communicate and
expose javascript API’s across domain
boundaries.
..
At the core easyXDM provides a
transport stack capable of passing
string based messages between two
windows, a consumer (the main
document) and a provider (a document
included using an iframe). It does
this by using one of several available
techniques, always selecting the most
efficient one for the current browser.
For all implementations the transport
stack offers bi-directionality,
reliability, queueing and
sender-verification.
I'm currently working on a web application that customers can add to their webpages by adding a javascript link to a js file on my server. The application read all the javascriptfiles from my sever, but I still get an error when trying to use ajax to get data from my database. I didn't think that would be a problem because the files is on my server.
Can I fix this or do I have to make a cross-browser solution? I don't have any control over the costumers server.
Thanks in advance
Mikael
This is not possible: When you execute a remote script, it runs in the context of the containing document.
There are some popular workarounds for this:
Using an iframe, which fixes the cross-domain problem but doesn't integrate well with the remote site (e.g. no custom styling)
Using JSONP to make cross-domain Ajax requests (detailed explanation here)
Using a server-side proxy script (not an option in this scenario)
Using YQL (I'm not familiar with this but it's said to work)
The same origin policy is based on the host document not the script itself.
You need to use a cross domain ajax technique.
if in the website http://www.mysite.com there's an external js file added as
<script src="http://www.yoursite.com/new.js"></script>
within the http://www.yoursite.com/new.js js file, there's an ajax call to a script in http://www.yoursite.com/new.js
in such a case will there be the same-origin policy security problem, as it's calling a script in a site from another website?
There will be a problem. new.js run in the scope of mysite.com, not yoursite.com.
EDIT: a more detailed explanation would be: when mysite.com is openning a tag, that script runs in the scope of the current page. The source of the script does not matter: it can be inline, local source, or remote source, it is still considered part of mysite.
As you know, scripts in mysite.com cannot access anything on yoursite.com due to the same origin policy. So you cannot do this.
As an advanced option for cross-origin communication look at jsonp. It will require yoursite.com to provide a special handling, but if you have control on both sites then this should not be a problem.
JSONP is precisely what you're looking for: http://en.wikipedia.org/wiki/JSON
The 5,000m overview is that JSONP uses the same mechanism for requesting external scripts as you're using above. The difference is that your server will recognise this and will package up the JSON response as the argument to a callback method. When your site receives this 'script', it executes it thereby returning the data directly into your callback method.
If you are able to use a framework like jQuery, most of the client side would be transparently handled for you. Check it out here: http://api.jquery.com/jQuery.getJSON/