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 !
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
I have a problem on my SSL website. I tried to add an external JavaScript link to my website. The JavaScript link is http and my website which is https, locks the script link for be http. This is the code of the script in http:
<div class="container radio">
<p>Próximo evento: 29/04/16</p>
<script type="text/javascript" src="http://player.wavestreamer.com/cgi-bin/swf.js?id=1SCZICL137KEA3GK"></script>
<script type="text/javascript" src="http://player.wavestreaming.com/?id=1SCZICL137KEA3GK"></script>
</div>
</div>
Is there any way my site https display the content?
The link of my site is this: https://www.insidecraft.com/radio.html
My second website whose haven´t got SSL works perfectly with is exactly the same code: http://us.insidecraft.com/pruebas2/radio.html
Thanks for your attention.
This is because browsers block active mixed content. You could configure the browser to allow it (at least in firefox). But this only works if you could change the configuration of all browser visiting your site (e.g corporate-network). Only other option is serving the script over HTTPS aswell. As workaround you could also put it in an <script> tag inside the document, served securly. Or copy the script to your HTTPS doamin. MDN on mixed content
If you load the page with your browsers development console opened, it should show an error saying that mixed active content has been blocked.
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.
I have my page which has a google map in the middle. It works if I load the page thats saved on my on desktop but not if i load from my dropbox for Chrome or IE. It only works in FireFox. Can anyone tell me why?
https://dl.dropbox.com/u/32241044/Blue%20Wolf%20Coding/page.html
Check out the developer console in Chrome and you'll see the following message:
[blocked] The page at https://dl.dropbox.com/u/32241044/Blue%20Wolf%20Coding/page.html ran insecure content from http://maps.googleapis.com/maps/api/js?key=AIzaSyDoXopD-LqdzB0iH92fs09t_YDjyo9rX_4&sensor=true.
This means that Dropbox prevented the Google Maps API from loading. When you're running the page locally, you're accessing it with an HTTP URL, but Dropbox has SSL on it. Change your include of the Google Maps API to include the HTTPS version:
<script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?key=API_KEY&sensor=true"></script>
You need to use protocol-relative paths like this:
<link rel="stylesheet" href="//example.com/style.css">
<script src="//example.com/script.js"></script>
check this answer:
How to Include CSS and JS files via HTTPS when needed?
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" )