We are loading the disqus embed.js library over https...going as far as to specify https as opposed to leaving the protocol out:
<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>
Everything works fine with loading in the comments iframe...the problem occurs when someone tries to include an image in their comment.
It appears that the disqus iframe is posting the image using http, as opposed to https, so the image preview that is returned is being blocked by the browser (because the iframe was loaded from https), and disqus is seeing it as an error and throwing up a warning message:
Screenshot: http://i.imgur.com/idA1NUV.png
We confirmed that if we served the site over http and loaded embed.js from http as well, everything works fine. So it looks pretty definite that the mismatched protocol is the issue.
Is there any way to make sure the disqus code properly uses https when doing the image upload??
We don't currently have support for https image uploads. We're aware that this limitation is kind of a bummer, so this shouldn't be the case forever.
Related
I'm using the new Google reCaptcha API for a contact form inside a page on my wordpress instance, but the API returns a 500 Internal Server Error message when using the script given by Google.
So, I'm using this code to make it work
$siteKey = "sitekey";
$secret = "secretkey";
$lang = "it";
$resp = null;
$error = null;
$reCaptcha = new ReCaptcha($secret);
if ($_POST["g-recaptcha-response"]) {
$resp = $reCaptcha->verifyResponse(
$_SERVER["REMOTE_ADDR"],
$_POST["g-recaptcha-response"]
);
}
and, on the HTML:
<script src='https://www.google.com/recaptcha/api.js'></script>
<div class="g-recaptcha" data-sitekey="<?php echo siteKey; ?>"></div>
But, when i open that page, the only thing I see is this:
An error occurred:
An internal error occurred: 50C0C9A3E5F28.AB460A3.4C003672
By the way, on Google Chrome console i can click on the URL generated by the API's script, and, when I open it, I see a blank page with the reCaptcha I needed.
Could it be a conflict between Google reCaptcha API and Wordpress or is it just an API's error?
you got this error because you didn't put in your domain into Key Settings in recaptcha admin site or basically wrong domain.
I've solved the problem, but the funny thing is that I don't know how, I've just re-copied the code from Google Documentation, maybe there was a mistyping.
Anyway, problem solved.
I'm trying to set up my first AJAX dev site on MAMP. The image below shows my file structure inside a folder htdocs/javascriptAJAX/
The code in my app.js file is :
(function(){
var request = new XMLHttpRequest();
request.open('GET', '/data.txt');
request.onreadystatechange = function() {
if ((request.readyState===4) && (request.status===200)) {
console.log(request);
}
}
request.send();
})();
When i look in my console though, I'm getting the standard denial because of cross-origin requests:
XMLHttpRequest cannot load file:///data.txt. Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.
How do I correct this? Surely if this is being run on MAMP it would have the same server?
Many thanks,
Emily
This problem was caused by the trailing forward slash in the .open() method.
Removing it solved the problem.
Since yesterday, I got mixed content errors on my website in both Chrome and IE. The error is provoked by the Google Translate script included in the header:
<script type="text/javascript" src="//translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"></script>
I downloaded the file element.js and eventually figured out where the bug comes from:
var s = window.location.protocol == 'https' ? 'https' : 'http';
Using (any) browser console, we can see that the expression "window.location.protocol" returns "https:" (and not "http") in all secure websites. Therefore, the script tries to load a bunch of CSS/JavaScript resources it needs, prefixing their URL with "http" instead of "https".
Which results in the following errors (one per resource):
The page at https://mysite.com ran insecure content from http://translate.googleapis.com/[something].css
The Google Translate tool is really useful to my users so I cannot remove it. Also, I tried to download the script and run it locally but it doesn't work. I spent a lot of time on that issue, am I the only one in that situation or something changed recently in the Google Translate script?
[EDIT]
I just took a look at the Google Analytics code and found that:
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www');
This reinforces the idea that the Google Translate script should test for "https:" too.
I'm having issues with using $http on ie8. The request does not reach the server, until I hit a refresh. Coming back to the same link still has the same problem until I hit refresh again.
The weird thing is if the web server is on LAN and the request is made to a server in LAN, it works fine. But if the webserver is hosted remotely, it does not work!
Here is the code:
Index.html
{{test}}
Controller
app.controller(
"TestController",
function( $scope, $http) {
var url = '/test/get_data';
$http.get(url).success(function(data) {
$scope.test = data;
});
}
);
I got this error: TypeError: Object doesn't support this property or methodundefined
I prepared a JSFiddle earlier but JSFiddle is broken in ie8 so I don't provide it here.
Unfortunately I don't have a remote server that I can share with you.
Edit
Previously I used an external url which gave me 'Access Denied' error in ie because of Same Origin Policy as mentioned by one answer below. But this was not my original problem. I still have the issue above when request is from the same origin
This is a cross domain request, which is not allowed in ajax because of Same Origin Policy.
There are two solutions for this
1. JSONP: It is a cross browser way to handle cross domain ajax requests using javascript callback mechanism
2. CORS: It is a HTML5 standard, it is implemented by most of the modern browsers except IE
Mongodb lab is not supporting jsonp since it has support for CORS, that is why your request is failing in IE and works in Chrome and other browsers.
As per this post they do not have any plan to support jsonp, so I don't thick there is a way to make this work in IE.
So I found the fix... Hope this helps anyone out there that experience this problem
Angular script needs to be loaded after jQuery. I didn't have this because Yii framework that I use autoloads jQuery and the angular was not included after the jQuery.
All the controller functions need to be at the end of body section (just before the closing )
Updating to angular 1.0.5 seems to fix the problem. The problem occurred in 1.0.4 with all the above tricks. I think is related to fix 791804bd
I have code that uses Microsoft's XDomainRequest object in IE8. The code looks like this:
var url = "http://<host>/api/acquire?<query string>";
var xdr = new XDomainRequest();
xdr.onload = function(){
$.("#identifier").text(xdr.responseText);
};
xdr.open("GET", url);
xdr.send();
When the scheme in "url" is "http://" the command works fine. However, when the scheme is "https://" IE8 gives me an "Access denied" JavaScript error. Both schemes work fine in FF 3.6.3, where I am, of course, using XmlHttpRequest. With both browsers I am complying with W3C Access Control. "http://" works cross origin for both browsers. So the problem is with IE8, XDomainRequest, and SSL.
The SSL certificate is not the problem. If I type https://<host>/ into the address bar of IE8, where <host> is the same as in "url" above, the page loads fine.
So we have the following:
- hitting https://<host>/ directly from the browser works fine;
- hitting https://<host>/api/acquire?<query string> via XDomainRequest is not allowed.
Can it be done? Am I leaving something out?
Apparently, the answer is here: Link
Point 7 on this page says, "Requests must be targeted to the same scheme as the hosting page."
Here is some of the supporting text for point 7:
"It was definitely our intent to prevent HTTPS pages from making
XDomainRequests for HTTP-based resources, as that scenario presents a
Mixed Content Security Threat which many developers and most users do
not understand.
However, this restriction is overly broad, because it prevents HTTP
pages from issuing XDomainRequests targeted to HTTPS pages. While it’s
true that the HTTP page itself may have been compromised, there’s no
reason that it should be forbidden from receiving public resources
securely."
It would appear at present that the answer to my original question is: YES, if the hosting page can use the "https://" scheme; NO, if it cannot.