I'm loading Disqus on a page loaded via HTTPS with the following code, as suggested in this answer.
<div id="disqus_thread"></div>
<script type="text/javascript">
var disqus_shortname = 'our-shortname';
(function() {
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
dsq.src = 'https://' + disqus_shortname + '.disqus.com/embed.js?https';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
})();
</script>
Note that I've changed the request of embed.js to be https rather than http, and I've added ?https to the end of the request too, which I believe is supposed to force HTTPS.
The initial request goes via HTTPS as planned, but it makes a secondary request via HTTP, which Chrome is hating (I get the red cross over padlock icon).
From the Chrome console:
The page at https://our-website.com/blog-post-name ran insecure content from http://juggler.services.disqus.com/event.js?thread=635675380&forum=our-shortname...[long query string]
Is this the correct method to get Disqus to use ssl on all requests, or have I missed a step?
Thanks.
This looks to be an issue within Disqus itself. We had Disqus working fine via SSL with the same approach in a couple of Drupal sites, but both recently had Disqus begin causing SSL warnings in both IE and Chrome as you've described.
I did a bit of digging, and I see that the DISQUS.useSSL function that's defined in embed.js and called in thread.js updates a few URLS (specifically ["disqus_url","realtime_url","uploads_url"]) in the Disqus json settings object by replacing http in their URL with https if https is found in the settings. The juggler_url doesn't get the same treatment, and so it's not updated to load via SSL. I'm not sure what juggler's purpose is, but it appears that that URL (http://juggler.services.disqus.com/) won't load via SSL in any case, so even if it's url was changed to https, it still wouldn't work.
So perhaps Disqus has made a recent change, since we had this working previously? We're taking this up with them, since this doesn't appear to be a config issue on our end...
UPDATE:
Apaprently Disqus launched a new service that does not support SSL. This is what's generating the extra scripts that get loaded insecurely, thus triggering the security warning. Disqus disabled this new service (which they didn't tell us the name of) for our specific account, and now SSL is once again working as expected. So, the solution is to just ask them to make your account SSL compliant, and that should take care of it.
Found this article, which hands the solution:
http://help.disqus.com/customer/portal/articles/542119-can-disqus-be-loaded-via-https-
Basically it's not possible (yet) with Disquss 2012, but switch it off and change the embed src so it uses https:// and add the ?https param:
dsq.src = 'https://' + disqus_shortname + '.disqus.com/embed.js?https';
I have had this problem off and on for the past few months and have been forced to disable Disqus altogether. Initially I contacted Disqus to see if they could make the switch that disabled the non-SSl compliant feature on their side and this worked for a while but the mixed content problem kept re-occuring.
What seems to happen is that despite Disqus forcing the https version of its count.js javascript, count.js still redirects to mediacdn.disqus.com instead of securecdn.disqus.com for some reason. If one appends ?https manually in the plugin editor to force the redirect to the securecdn.disqus.com, the problem disappears in the first call to the CDN but in subsequent calls to the CDN with the query string ?https added to the count.js call, the redirect just reverts back to mediacdn.disqus.com. I've tried this numerous times.
The annoying thing about this issue is that the SSL page in question on my site creating the mixed content notification does not even have a comment section. So Disqus is loading its javascript needlessly on the page.
I like Disqus but it's unbelievable to me they wouldn't fix this issue by either allowing users to disable the javascript selectively or by implementing a secure cdn version that works in all cases. I am hoping they figure this out.
Also they told me that Disqus 2012 doesn't support HTTPS (although it will be in the future).
Apaprently Disqus launched a new service that does not support SSL. This is what's generating the extra scripts that get loaded insecurely, thus triggering the security warning.
Related
I'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.
I'm writing an app for Facebook, which needs to be secure. The initial page, https://myapp.com, loads perfectly fine.
However when I click a link to https://myapp.com/link, Chrome complains that the app is trying to load from an insecure source. I get the following message in the console:
"[blocked] The page at 'https://www.facebook.com/page/app_###' was loaded over HTTPS, but ran insecure content from 'http://myapp.com/link/': this content should also be loaded over HTTPS."
Now the link is an absolute URL with the https prefix, yet apparently the page is trying to load from the http version.
I visited the domain itself and checked the Network tab in the Chrome console to see what was happening. The following happens:
The GET to https://myapp.com/link is a 301, moved permanently.
This then redirects to http://myapp.com/link
As far as I can tell, there is nothing in my python code to make this happen, so I suspect some feature of Heroku is causing this, but I haven't been able to find anyone else with this problem.
As a side note, I used Flask-SSLify to add a redirect back to the https version. This redirect works, but Chrome still blocks the page because it passes through the insecure version.
I feel so stupid for working this out five minutes after posting the question, but it is a little obscure.
It turns out the problem was that the page I was attempting to reach was "https://myapp.com/link/" with the trailing slash.
"https://myapp.com/link" redirects to "http://myapp.com/link/".
I don't know why the protocol isn't preserved by this redirect, it may be either Flask or Heroku, though I suspect it is Flask. Regardless it seems like a bug.
Hope this winds up helping somebody else.
I am developing a Rails application that uses SSL connection. I am currently using third party resources that are js and css files for implementing a map (OpenStreetMap) . I have already tried to import these resources (js and css) into my application, but the javascript code tries to access an external WMS via HTTP.
The problem is that Google Chrome is blocking access to third-party resources from HTTP when the application is in HTTPS.
So I disabled SSL on a certain pages of the application and tried to force the HTTP or HTTPS the way I desire.
Following this blog: http://www.simonecarletti.com/blog/2011/05/configuring-rails-3-https-ssl/ and it works.
But when I force the HTTP protocol to the page where these resources will be used using Google Chrome, it forces HTTPS connection causing infinite loop.
If I clear the Chrome cache (that have already accessed the same page with HTTPS) in order access it via HTTP it works. But if I have accessed a HTTPS page and try to access via HTTP, Chrome forces the HTTPS connection resulting in an infinite loop.
The question is: Is there something I can set in the request that causes Chrome to accept the connection?
Regards
I've been doing some research on this, and it turns out that turning on force_ssl = true on Rails 3 causes the app to send an HSTS header. There's a bit of information about it here: How to disable HTTP Strict Transport Security?
Essentially, the HSTS header tells Chrome (and Firefox) to access your site only through HTTPS for a specific amount of time.
So... the answer I have for you now is that you can clear your own HSTS setting by going to about:net-internals within your Chrome browser and removing the HSTS state.
I think the answers here can help you: Rails: activating SSL support gets Chrome confused
I run a secure website on Apache, but one part requires YouTube videos that aren't showing due to the SSL blocking them.
I therefore need to use HTTP for this part of the site (/videos). If I delete the 's' off https, it jumps back in there so can't simply change the link to it.
Is there a mod_rewrite code or something similar that might add an exception to this directory?
Switching from HTTPS to HTTP will always cause problems, especially if your users are authenticated and if you want to maintain security.
You could use YouTube via HTTPS instead, as described on the YouTube API Blog.
I'm building a site with Umbraco, and there are a couple of pages that need to be visited over HTTPS instead of HTTP (e.g. a login page).
I've seen a couple of macros that get put on the page that needs to use HTTPS, and essentially just check the protocol used and do a Response.Redirect with the correct protocol if necessary. This seems like a terrible way of achieving what seems to be a fairly basic requirement - ideally I'd want Umbraco to render any links to these pages as <a href="https://...", not do a redirect when the user goes to a page.
With these redirecting macros, there's also the possibility of a browser displaying a warning if the user's on an HTTPS page and navigates to a HTTP one. If the links are relative, the user will be redirected from HTTPS to HTTP, and the browser may warn about this.
Is there a way to achieve this without modifying any Umbraco framework code?
There's currently no built-in way to make a few pages in Umbraco return a https url.
The only way I can think of doing this at the moment is just by making sure that you set up your links correctly.
But there's no way of stopping people from entering the insecure link. That is where the redirects come in handy though, it will make sure you don't get to a secure page insecurely.
I would recommend running the whole site in https mode. In the past, performance would have been an objection to running your full site in https mode. However with modern servers, this really shouldn't be a problem any more.