How to create Web Worker from script served from subdomain? - javascript

I have a website at example.com and I am serving all external resources from cdn.example.com. So in my HTML page at example.com I have something like:
<script type="text/javascript" src="http://cdn.example.com/script.js"></script>
In my script I want to create a Web Worker, so I do:
worker = new Worker("http://cdn.example.com/script.js");
But this fails on Firefox 16 with Failed to load script: http://cdn.example.com/script.js (nsresult = 0x805303f4) error. It works on Safari 6 and Chrome 22.
It seems the problem is because origins differ. Effective origin of the script is example.com and cdn.example.com does not match that. This seems a bug because not CORS not setting document.domain helps (or at least I couldn't make it to work by playing with that). Is there any way to make it work?

At the end I made website at example.com serve a simple JavaScript code which includes the real web worked code:
importScripts('http://cdn.example.com/script.js');
and then create web worker by pointing to that.

Related

Loading script from HTTP is automatically converted to HTTPS for some users

I am trying to load socket.io using the following code:
<script src="http://cdn.socket.io/socket.io-1.4.5.js"></script>
However some users have reported the following error to me:
Failed to load https://cdn.socket.io/socket.io-1.4.5.js ERR_SSL_PROTOCOL_ERROR
Is this an automatic security setting on modern browsers? And if so can it be disabled?
The problem is not your fault!
Accessing that link in my browser fails as well, and inspecting the unsuccessful request shows that the following header was set:
Upgrade-Insecure-Requests: 1
This tells the browser to "upgrade" all http:// URLs to https://, which seems to mirror the error your users are reporting.
ERR_SSL_PROTOCOL_ERROR indicates that the SSL certificate for https://cdn.socket.io/ is incorrectly configured and thus the browser (rightly) assumes the worst, and chooses not to trust data served from that domain over the secure protocol. When the domain is configured to "upgrade" insecure requests to secure ones, and secure requests are rejected by the browser, it becomes clear why there is no way to access the content correctly at either URL.
I would contact the administrators of the website and inform them of the problem, or just simply switch to another CDN like Chris Chen suggested:
<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/1.4.5/socket.io.min.js"></‌​script>
Sounds like the users who are experiencing that error are hitting the https version of your page. Best way to deal with this issue is by changing your code to:
<script src="//cdn.socket.io/socket.io-1.4.5.js"></script>
Or
<script src="https://cdn.socket.io/socket.io-1.4.5.js"></script>
The former is preferable (because it is faster for http users) unless you are working with an .html or .htm page and want to open it without a web server.
The link is not working at all from anywhere. Is it a private link that require certification?
If you just want socket.io.js, use link from https://cdnjs.com/libraries/socket.io

Chrome extension breaks HTTPS on all URLS being loaded

Chrome extension breaks HTTPS on all URLS being loaded.
Any suggestions on where to start looking for the cause?
The status of the connection as given by Chrome is:
Your connection to this site is private, but someone on the network might be able to change the look of the page.
screenshot
Disabling the extension resolves HTTPS.
Copy the extention script and place it on your server.
So you can access it without refering to a <script src="http://...>.
But a <script src="/path/to/this/js/on/your/server" ...>.
The problem isn't the extention itself, but it's location.

How to force loading dynamic, insecure content in Chrome?

I'm using Jira in https and I have some adjustments I'd like to make with some extra JS. My JS is hosted on an insecure server (no https available).
When I dynamically load the insecure JS file by inserting it into the DOM (using a browser extension), Chrome tells me:
[blocked] The page at https://jiraserver/browse ran insecure content from http://myserver/jira.js.
I can see how this is very secure and all, but I don't care. I want to load that insecure JS file. How can I tell Chrome to trust me and just do what I say?
My insertion method (in the extension code):
document.body.appendChild((function(s){s.src='http://myserver/jira.js';return s;})(document.createElement('script')));
According to this Chrome Support Q&A you can launch your Chrome with the following command line flag to prevent Chrome from checking for insecure content:
--allow-running-insecure-content
Here is some documentation on how to run Chrome with command flags
Chrome simply will not load an insecure script in a secure page.
Does your jira.js have to be loaded from a server? The best way to inject it into the page would be by including it in your extension bundle.
var s = document.createElement('script');
s.src = chrome.extension.getURL("jira.js");
s.onload = function() {
this.parentNode.removeChild(this);
};
(document.head||document.documentElement).appendChild(s);
If you must load it from a server, I suppose your extension could make a XHR request for the script, then inject the response into the page.
// make a XHR request, then...
var s = document.createElement('script');
s.textContent = codeFromXHR;
(document.head||document.documentElement).appendChild(s);
s.parentNode.removeChild(s);
I had the same problem:
Our client link a CSS file and js file hosted in our server on a domain which is not secure.
We will solve it by using Amazon CloudFront. They server HTTPS using their certificates which is verified.
That's not a bad solution for use since CDN is often a good idea and these resources are somewhat static. (The CSS file is tailored for each client and is in fact generated but a sane TTL can be configured and the CDN flushed if required)
Note that the CDN solution may even be more affordable than actually buying a certificate depending on your data load.
I have faced the same issue and find that if we are logged in to our google account in chrome then Chrome stop loading the insecure content in https.
If we use incognito window in to load the website which has insecure content then it will work.

ftp:// web page in FF and Chrome does not load file:// script

I'm building a web page which I can only access by ftp:
ftp://192.168.0.1.cutthis/mypage.html
This url opens the page in the browser as I would have used http protocol.
The page contains a dynamic GUI. To make its development easier, I have moved all the javascript to a machine (192.168.0.2) I have access to, so I can edit it more quickqly. In the html source code of mypage.html, the script line is:
<script type="text/javascript" src="file://///192.168.0.2/myscript.js"></script>
FF and Chrome load the script (Firebug confirms this) but don't run it. Only IE run it.
How can I force FF and/or Chrome to run the script? Or how can I solve the problem overwise?
cross-protocol scripting?
Method 1:
For Chrome try extension: LocalLinks
For FF try extensions: LocalLink, Local Filesystem Links, IE Tab
Method 2:
run Chrome with --allow-file-access-from-files flag
or may be try other flag which disables cross-site scripting (waring: this is dangerous)
configure Security Policy in FF (create special policy for your site - read here: Links_to_local_pages_don't_work, Security_Policies)
But, I'm still not sure if all of this helps. FTP: URL is a special case
MDN says of the same origin policy:
The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin.
myscript.js is from the origin file:////192.168.0.2/ but it is being loaded into a page with the origin ftp://192.168.0.1.cutthis. My guess is that the cross-domain script cannot perform the manipulation you expect it to do because it is loaded from a different origin.
The solution would be to host both the script and the page on the same origin (i.e., also serve the HTML page over file://, or even better, serve them both on a local HTTP server).

Opera won't load some JavaScript files

I have a web page that loads in an IFRAME, that runs correctly in IE and Firefox but not in Opera. Which I hate, because I've been an Opera user for years. And I wrote this thing. :-)
The problem is that Opera is not loading some of the JavaScript files that comprise the page. I suspect that it is related to the fact that the page itself is loaded via HTTPS and the included files via HTTP from a different host and port. I believe Opera allows that, but Dragonfly's Net tab doesn't even show an attempt to load them.
The page is a Rally "custom app", and I can't control the fact that it is loaded in an IFRAME or that it loads via HTTPS. I also can't control the fact that the included files are loaded from a different host, or that the host only supports HTTP. So I'm sorta stuck with mixed content.
Among other stuff, the page's HEAD element contains (sanitized a bit):
<script src="http://www.example.com:81/common/jquery-1.4.2.js"></script>
<script src="http://www.example.com:81/common/jsTree/jquery.jstree.js"></script>
<script src="http://www.example.com:81/common/utils_jserror.js"></script>
<script src="http://www.example.com:81/common/utils_logging.js"></script>
<script src="http://www.example.com:81/common/utils_print_r.js"></script>
<script src="http://www.example.com:81/common/utils_rally_query.js"></script>
<script src="http://www.example.com:81/common/json2.js"></script>
<script src="/slm/js/slm.js"></script>
<script src="/slm/js-lib/dojo/rally-1.3.1/dojo/dojo.js.uncompressed.js"></script>
<script src="/slm/mashup/1.18/js/batch-toolkit.js"></script>
<script src="/slm/mashup/1.18/js/utilities.js"></script>
ALL of the "/slm/..." stuff is getting loaded, and NONE of the "www.example..." stuff is.
Anybody got an idea what I'm doing wrong?
Opera has a feature called cross-network protection. Basically it places some extra limitations on what pages from the internet can do with stuff on your local network.
The reason this feature exists, is the emergence of the so called "phish farm" exploits, where it was discovered that the HTTP-based config screens of some popular home routers / modems were so poorly secured that malicious web pages could rewrite your router settings - for example to configure it to use a proxy and pipe all your traffic through a malicious server. To counter this, Opera knows that some IP addresses are not used on the public web (such as 127.0.0.1 or 192.168.*) and it doesn't allow pages from a "public" site to load files or send requests to a "local" site.
You can reconfigure this on a per-site basis. The easiest thing is probably adding an IFRAME on the "public" site loading one of the resources from the local server. The IFRAME will show a "cross-domain request" warning page with some opt-in links. Click the link for always allowing local requests from that server, and voila - your cross-network app should now work again.
(Adding an IFRAME is as easy as viewing source, adding <iframe src="http://local/whatever/included/file.js"></iframe>, saving, and "Tools > Advanced > Reload from cache" )

Categories

Resources