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" )
Related
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
This is one of those issues where I'm going to punch myself in the face for not figuring out, but here goes anyway.
I've got a simple Laravel app (Laravel really has nothing to do with this anyway) and I need it to load its assets. The problem is, nothing loads. If you view page source and click on one of the links to the asset, it loads fine. If you view the network panel in firebug, no requests are even made for the files. That's 0 requests being made for the files.
I should mention, though, that this only happens in firefox. An item of note is that this page is served over HTTPS via self signed certificate (it's on a dev machine). Chrome and Safari both load the assets fine.
Let me know if you need any more information and I'll be happy to provide.
Here are some screens
It might be that you are using a http protocol for the resources whereas your page is being served with a https protocol as you say. Match the protocol for the page with the protocol for the resources that you are loading. e.g. You could use //: rather than http:// or https:// for your resources.
This issue was very obscure, and I didn't find it until starting Firefox in safe mode. This disabled all addons. When I did that, the page worked fine. The source of the issue was Adblock Plus. After disabling that addon the page works just fine. For some reason Adblock Plus doesn't play well with certain pages over HTTPS, so it may be a bug for them, or the page I was trying to load is being blocked by Adblock (don't know why, it's just a dev machine)
I've simplified the code to hopefully make it easier to figure out.
HTML
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.11/jquery-ui.min.js"></script>
<script src="script.js"></script>
<link rel="stylesheet" type="text/css" media="all"
href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/smoothness/jquery-ui.css"/>
<div type="text" id="datepicker">
Javascript
$(function() {
$("#datepicker").datepicker();
});
I've uploaded both my HTML and javascript files on my school's hosting space here. When I visit the link on Safari the calendar shows up fine but when I open it on Firefox or Chrome nothing happens.
Any help would be appreciated!
Your schools hosting uses SSL, so it's an https:// link.
When a user visits a page served over HTTP, their connection is open for eavesdropping and man-in-the-middle attacks.
When a user visits a page served over HTTPS, their connection with the web server is authenticated and encrypted with SSL and hence safeguarded from eavesdroppers and man-in-the-middle attacks.
However, if an HTTPS page includes HTTP content, the HTTP portion can be read or modified by attackers, even though the main page is served over HTTPS.
When an HTTPS page has HTTP content, we call that content “mixed”. The webpage that the user is visiting is only partially encrypted, since some of the content is retrieved unencrypted over HTTP.
Chrome and Firefox now has Mixed Content Blockers that blocks certain HTTP requests on HTTPS pages.
For security reasons Firefox and Chrome will block any scripts not loaded from a https adress when the page loading those scripts is using https.
To fix it, simply change the URL's of your scripts from
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
to
https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
Google supports both.
And use a current version of jQuery, version 1.4 is half a decade old !
I am using flexible css box model in one of my web application. For cross browser compatibility in IE, I am using the flexie.js pollyfill. I have got it working perfectly fine on my local machine as well as on my production environment. However, the problem starts when i try to serve my static files( css, javascript and images) from a subdomain instead of the naked domain. The flexie.js file is loaded in ie, however it doesn't seem to do anything when i serve static content through sub-domain. As soon as i change my config to use naked domain for serving the page, flexie.js renders the page appropriately. I don't see any ajax in play here and all my other script files work perfectly fine when i use the subdomain. I don't think this makes any sense, and am sure there is some other reason for the same.
Seems like a limitation of flexie.js (which gets its CSS parsing from selectivizr) is that the static files and webpage must be on the exact same domain:
http://selectivizr.com/#things
(linked from https://github.com/doctyper/flexie)
Style sheets MUST be hosted on the same domain as the page due to browser security restrictions. Likewise, style sheets loaded using the file: protocol will not work.
Let's say I'm developing bunch of JS widgets that are intended to be embedded on any webpage (sort of iGoogle, Pageflakes widgets).
The client can embed the widgets by including a script tag:
<div id="widgetHost">
<script src="http://fantasticwidgets.net/awesomeWidget.js"></script>
<script src="http://fantasticwidgets.net/awesomeWidgetAgain.js"></script>
</div>
Now these widgets rely on common libraries (let's jQuery, underscore, and some of my own - e.g. myCommon.js).
Ideally, this is what should happen:
Widget's bootstraper js is downloaded first
Widget's bootstraper js checks for presence of these library files with their required version (say whether jQuery v1.6.2 is loaded on the page or not, myCommon v1.1 etc)
If any of those is loaded, don't request those files, but download missing scripts only.
These scripts then call some webservice, do some magic and render HTML on page
Concern: Checking for files already loaded introduces a vulnerability of script spoofing. A malicious user spoofs the libraries once loaded which he uses to steal sensitive info or do other bad things.
Solution: Do not check for loaded libs, send all of them again always. This is still not bulletproof but at least makes it a little harder as he has to spoof again.
However, this causes wasted bandwidth and increased loading time.
Question: Is it possible to detect if the loaded files are tampered with, preferably on the client side? Or does it have to include a server side solution? I've ASP.Net running on the server side if that matters.
The only real solution here is "use HTTPS to deliver the scripts." If the bad guy can go so far as to poison the user's browser cache with HTTPS content from another domain, it's already game over for you, because he would also have power to change the page you deliver to the user.