I'd like to use window.location.href in the tool codesandbox.io. This is because I want to do a test with a hard page load occurring. I'm running into an issue however.
location.href = "http://www.google.com"
I get this error:
Mixed Content: The page at 'https://codesandbox.io/s/lingering-bird-nyvfi' was loaded over HTTPS, but requested an insecure resource 'http://www.google.com/'. This request has been blocked; the content must be served over HTTPS.
Example: https://codesandbox.io/s/locationhref-usage-nyvfi (see src/index.ts and open Dev Console)
How do I accomplish this the ability to simulate a page load, in the fake virtual browser?
I think it may be possible once the security criteria are met; which is limiting.
Use HTTPS (Avoid mixed content)
Use same origin
Thus this works:
window.location.href = "https://www.codesandbox.io/docs";
Related
I've uploaded a new static blog to GitHub Pages using Ghost and Buster.
Github Repo: https://github.com/paddy420Smokers/cannalogie
I've added the code below to force all pages to use https:// , on the Frontpage and Category Pages its working fine, but on Posts only https:// is there but it's not fully secured.
<script>
var host = "cannalogie.net";
if ((host ==window.location.host) && (window.location.protocol != "https:"))
window.location.protocol = "https";
</script>
Does anyone know how to fully secure all pages and posts?
Looking at the developer tools, it looks like you're loading something that over http while the rest of your page is loaded over https. That causes the whole page to be considered insecure and not show the lock symbol, even if the url shows https.
It looks like you're loading a .gif over http. If you change the url to load it over https, the error should go away and the lock should appear.
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 want to make our TYPO3 v4.5 website accessible by HTTP and HTTPS. I already configured SSL for Apache and requesting the main page displays it... partially.
The baseurl within the page links to my http-site (and is not a https-URL), and therefore the browser won't load the css files, because they come from an unsafe part of my domain.
I believe I could switch my whole site to HTTPS, but don't want it. I would like that when the site is called by HTTP, all URLs are generated as http:// and when called over SSL, all urls should be generated as https:// URLs.
Did anybody achieve something like that?
Use a TypoScript condition to output the base URL dependent on the used protocol:
config.baseURL = http://example.com
[globalString = ENV:HTTPS=on]
config.baseURL = https://example.com
[global]
That's a bit ugly (as both variants will not share caches), but Protocol-relative tags are not possible. The only alternative (to baseURL) is config.absRefPrefix.
I have just set up SSL on my site https://helloacm.com and the home page is OK but this URL https://helloacm.com/milestones/ browsing in Chrome shows “The site uses SSL, but Google Chrome has detected insecure content on the page.”
I have googled a lot and almost every article says that I should change all http to https for images, css and links.. but I have viewed the source code and found out there are not references to http://helloacm.com any more.. so I don't get it , why this url still shows error.
Look in the console. For me, it says:
Mixed Content: The page at 'https://helloacm.com/milestones/' was loaded over HTTPS, but contains a form whose 'action' attribute is
'http://www.google.co.uk/'. This form should not submit data to
insecure endpoints.
Mixed Content: The page at 'https://helloacm.com/milestones/' was loaded over HTTPS, but requested an insecure image
'http://uploadbeta.com/_s/upload/2014/09/04/1137292dd6fbe2b75f1373cb0e3c7a1c.jpg.jpg'.
This content should also be served over HTTPS.
Mixed Content: The page at 'https://helloacm.com/milestones/' was loaded over HTTPS, but requested an insecure image
'http://uploadbeta.com/_s/upload/2014/09/26/eb174fb4bab9f8cba5ef25fb0321234f.jpg'.
This content should also be served over HTTPS.
Mixed Content: The page at 'https://helloacm.com/milestones/' was loaded over HTTPS, but contains a form whose 'action' attribute is
'http://www.google.com/'. This form should not submit data to insecure
endpoints.
Simply fix the errors here, and that warning will go away. Also, regarding the second error: why are you requesting a .jpg.jpg? For me that simply reduces the quality. Just change that to a .jpg.
Just wanted to throw in another answer here for those of you who have tried everything and are still getting this error message.
With some hosts, like WP Engine, where you have yourwebsite.com but then another version of your site like yourinstall.wpengine.com (MediaTemple has something like this, and probably lots of other hosts), and especially if you built / developed the site at that temporary URL, and then set things up to forward the install to your actual URL...do a check in your database, because depending on how the forwarding works at the server level, you might see https://yourwebsite.com/my-image.png and be baffled, but in the database the actual image being served is still from the temporary domain.
Had me baffled forever!
You must set the "$config_location_base" as https://yoursite.com directive in your config.
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.