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.
Related
I am trying to make an SEO friendly link for a downloads page
using codeigniter hosted on Azure Websites, now this is working:
www.example.com/downloads/viewfile/34
now when i generated this link :
www.example.com/downloads/viewfile/my-nice-file-name-34
the Url rewrite works great locally on a WAMP server, but when deployed to the remote (Azure Webites IIS ?) it gives the error:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
I believe that the cause is: dash symbols are not allowed on IIS but is there a way arround ?
After all, i found out that its not the dash symbols that are causing the problem, but the words in the url itself
like yesterday i had www.example.com/downloads/viewfile/example-file-34
to some reason, having your domain-name in the url segments makes that error apear, so i simply replaced "mydomain" into nothing before generating the Url segment
$fileName = str_replace('mydomain','',$fileName);
return url_title($fileName.$fileId);
Now the same link above is www.example.com/downloads/viewfile/file-34 and its working fine.
i also noticed that same behavior is experienced when using some words like : ajax, json.
I hope this would be helful to somone.
In your routes.php file
Find
$route['translate_uri_dashes'] = FALSE;
Replace with
$route['translate_uri_dashes'] = TRUE;
You may need to look also into
URI Routing Codeigniter 3
http://www.codeigniter.com/user_guide/general/routing.html
Codeigniter 2 URI Routing
http://www.codeigniter.com/userguide2/general/routing.html
I am trying to build an "app version" of my website (a social network).
I am using PhoneGap + jQuery Mobile (i started learning them today).
The app simply needs to retrieve new posts from the website and show them to the user. Therefore I thought a simple Ajax Request would do the job.
So, i created a php test file on the server (URL: http://www.racebooking.net/it/moto/app/get_post_test.php), which simply Echoes Alien contact SUCCESS!
I've made a simple html page in localhost (on my PC) called index.html with a div called #post-container and an AJAX request:
var root = "http://www.racebooking.net/it/moto"
$.get(root + "/app/get_post_test.php", function(data){
$("#posts-container").html(data);
});
If everything is correct, i expect to see Alien contact SUCCESS! in the post-content div.
What happens looks strange:
If i run the app from eclipse using Genymotion, everything works fine
and i see the message Alien contact SUCCESS! -> the AJAX request
went fine
If i open the index.html file on firefox, i don't see anything
and FireBug informs me that the cross-origin request was blocked.
He also tells me to activate CORS.
1) Why is that happening and how can i make FireBug work (which is better and faster for debugging)?
2) Am i following the right procedure or i am missing something?
I found the solution from this post.
I just needed to add header('Access-Control-Allow-Origin: *'); at the top of my php file.
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.
Because of my free host's limitations, I need to call a cross-server request from a friends host where I uploaded a simple script.
I've set the headers in the script on my friends domain to allow cross server calls from my own host.
It works in google Chrome and Safari but doesn't work in FireFox (and IE).
Here is the particular line:
$.post("http://someothersite.com", {action : 'generate', usr: un}, function(url){
$("#thelink").html(url);
});
});
What am I overlooking? I've looked practically everywhere all day long trying to grasp what is going wrong. Obviously I am a noob, but just trying to learn here. Any help would be greatly appreciated.
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.