I have all my site images setup to serve from Amazon's Cloudfront CDN. If my pages will sometimes be served as both HTTP and HTTPS, then should I make all image paths HTTPS to the CDN?
Is this a poor practice?
Any other ideas?
Making all image paths to the CDN be over HTTPS is definitely a bad idea. There is a significant overhead with each HTTPS request, so you might not want to do that.
However, turns out there is a simple solution to specifying absolute, cross-domain URLs without the protocol. Simply use, in your css, something like
url: (//d604721fxaaqy9.cloudfront.net/image.jpg) ...
and make sure that your stylesheet is being served over the same protocol, either by using the same trick, or preferably by specifying a path without the protocol, i.e., something like
<link href="/styles.css" ...
or
<link href="styles.css" ...
and you're good to go!
Related
I just signed up for a cloudflare account and began forcing everything to https just to see how it worked, and to my surprise, all my images refused to work over https. now this is something I don't understand because the assets are all linked via:
HTML:
<img src="./images/image.jpg" />
CSS:
background-image: url(../images/image.jpg);
So I figured, I would change it up to use absolute urls with // instead of relative paths:
HTML:
<img src="//example.com/images/image.jpg" />
CSS:
background-image: url(//example.com/images/image.jpg);
this did not work either. so I decided to hard link to https:
HTML:
<img src="https://example.com/images/image.jpg" />
CSS:
background-image: url(https://example.com/images/image.jpg);
and again, not working. what happens is the images all buffer and as soon as they are fully downloaded and displayed,they disappear abruptly.
All of the images are available over https or http so I do not understand the issue here. Would appreciate a little insight into this and whether its a cloudflare specific issue or an issue with how I'm writing my code. Can anyone confirm that relative paths should call assets via whatever protocol is currently in use? ive not seen any issue with it in the past.
Thanks in advance
Odd problem.
Would appreciate a little insight into this and whether its a
cloudflare specific issue
In general, there should be no problem to do what you are asking, there's no CloudFlare issue
or an issue with how I'm writing my code.
Both of your code examples look good to me, the first perhaps preferable because it will work with both HTTP and HTTPS
<img src="//example.com/images/image.jpg" />
Have you
ruled out browser issues by testing with another browser?
cleared the CF cache?
tested with CF set to development mode?
ruled out any app related issues by testing https image loading on a plain HTML page?
tried changing the CF SSL Level (Flexible, Full, Strict)?
if still no joy, can you post a URL?
Good luck!
As it turns out this was a Cloud Flare issue. They have a feature called Rocket Loader, which compresses all your js files into one long minified JS file which was apparently causing one of my scripts to break, only when served over https. It has been raised as a bug with Cloud Flare support (as it is odd that it works over http but not https). This particular issue was with sss.js (Super Simple Slider) the solution supplied by Cloud Flare Support was to change my script tag for sss.js from:
<script type="text/javascript" src="js/sss.js"></script>
and adding data-cfasync="false" to the tag:
<script type="text/javascript" data-cfasync="false" src="js/sss.js"></script>
Apparently this extra bit of code makes Cloud Flare's Auto-Minifier and Rocket Loader ignore that particular file.
Hello i have an issue with my domain and ssl, when you enter to https://www.limitx.com.mx you can see a error with a ssl encryption, your connection is encrypted with modern cryptography, how i can solve this? i dont know how to fix this issue, i hope can help me. Bes regards guys!
You have two resources on your home page that are served over HTTP (mixed content).
Mixed Content: The page at 'https://limitx.com.mx/' was loaded over
HTTPS, but requested an insecure stylesheet
'http://fonts.googleapis.com/css?family=Roboto:400,900,300,700'. This
request has been blocked; the content must be served over HTTPS.
This is coming from the main file that is generating the HTML:
<link href='fonts.googleapis.com/css?family=Roboto:500,300'; rel='stylesheet' type='text/css'>
You'll need to change this to be
<link href='https://fonts.googleapis.com/css?family=Roboto:500,300'; rel='stylesheet' type='text/css'>
Mixed Content: The page at 'https://limitx.com.mx/' was loaded over
HTTPS, but requested an insecure image
'http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png'.
This content should also be served over HTTPS.
This is coming from https://limitx.com.mx/skin/frontend/ultimo/default/css/styles.css
.form-search .button {
...
background-image: url(http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png);
...
}
You cannot use an HTTPS version of this URL as the certificate for http://limitx.panamerik.net/skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/buscar.png does not match the host.
You can copy this file (buscar.png) locally, perhaps under skin/frontend/ultimo/default/images/infortis/_shared/generic-nav/ and change the CSS to be
.form-search .button {
...
background-image: url(../images/infortis/_shared/generic-nav/buscar.png);
...
}
Well the issue is that other objects on your page are not using ssl, do you have any embeded links that have http instead of say https? I would check those images, they are most likely the culprit. Instead of using relative paths try hardcoding all the images with https://url to image/ alright? That should fix ya up good. Nice site btw.
For your Firefox issues: https://support.mozilla.org/en-US/questions/967766
The only way for websites to "supply ownership information" would be through a secure connection and an "Extended Validation Certificate" which will cost a few hundred USD and upwards per year at the relevant certificate authorities: https://en.wikipedia.org/wiki/Extended_Validation_Certificate
Google Issues: https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1
Your connection to the site is encrypted, but Google Chrome has detected mixed content on the page. Be careful if you're entering information on this page. Mixed content can provide a loophole for someone to manipulate the page. This content could be third- party images or ads embedded on the page.
Internet Explorer.....doesnt see any issues at all.
We're getting allot of Mixed Content errors on the cart page of our Magento Store
Mixed Content: The page at 'https://www.magento.com/onestepcheckout/index/' was loaded over HTTPS, but requested an insecure stylesheet 'http://fonts.googleapis.com/css?family=Lato:400,300,700,900'. This request has been blocked; the content must be served over HTTPS.
I can see the google font file is being called in the head section of our theme via http
<link href='http://fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
I'm wondering what is the best way to solve this issue should I change the line above to:
Option 1
<link href='https://fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
OR
Option 2
<link href='//fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
Which is the best method considering most of our site uses http? I was not aware of Option 2, it seems like a very good approach.
I found a good answer here.
The second option, protocol relative links seems to be the best option.
UPDATED ANSWER
To give a more complete answer, protocol relative URLs help to avoid Mixed Content errors by requesting the resource from whatever protocol the browser is viewing that current page through. This is really useful when your site has pages that use both http & https, as in my case checkout page was being loaded over https while the rest our site uses http.
Example
So if we use a protocol relative url to link to a resource.
<link href='//fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
When we're on https://www.magento.com/onestepcheckout/index/ the resource will be loaded via https, https://fonts.googleapis.com/css?family=Lato.
And if we're on http://www.magento.com/ the resource will be loaded via http http://fonts.googleapis.com/css?family=Lato
This will avoid any Mixed Content Errors.
Caveats
There are a few things to consider when using this approach though.
IE6 does not know how to hanler protocol relative urls. IE6 has less than 1.7% of the browser market.
IE7 & IE8 support protocol relative URLs but they’ll end up fetching the
resource twice. Once from HTTP and once over HTTPS, which will slow
things down. Again, these older browsers account for very little of the browser market.
Does not work in all email clients (e.g Outlook), so avoid using protocol relative urls in HTML emails
You have to be sure that the server you’re requesting from is capable of serving content over both HTTP and HTTPS. If not you might end up fetching content from an unsecured or nonexistent server port.
Further Reading
https://developer.mozilla.org/en-US/docs/Security/MixedContent/How_to_fix_website_with_mixed_content
http://www.paulirish.com/2010/the-protocol-relative-url/
http://billpatrianakos.me/blog/2013/04/18/protocol-relative-urls/
I got the exact same error while adding products to cart, I was deploying CDN for Magento 1.9 let me share my solution,
Accoriding to Chrome Console, the URL returned by js about ajaxcart started with HTTP , so I go to review the parameter construture I found this :
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var myajaxcart = baseUrlAjax + 'ajaxcart/index/index/id/';
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var urladdajaxcart = baseUrlAjax + 'ajaxcart/index/index/';
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var checkouturl = baseUrlAjax + 'checkout/cart/add/';
and baseUrlAjax is controlled by PHP echo $url
app/design/frontend/default/theme691/template/cmsmart/ajaxcart/page/head.phtml: var baseUrlAjax = '<?php echo $url; ?>';
and $url is controlled by
app/design/frontend/default/theme691/template/cmsmart/ajaxcart/page/head.phtml >>>
#$url = Mage::getBaseUrl(); #oldone
$url = Mage::getUrl('',array('_secure'=>true)); # set to this new one
Bingo!
Reffered to this page : How Do You Get The Store Secure URL in Magento?
In Chrome I get the following error messages in the console
[blocked] The page at https://domain.com/home.html ran insecure
content from
http://domain.com/typo3temp/stylesheet_09c1ef800c.css?1345207892.
if I call https://domain.com. The user gets a page without stylesheets and images. What can I do against this?
The files are included like <script type="text/javascript" src="js/lib/jquery-1.5.1.min.js"></script> but I don't want to define the domain.
Should I completely switch to https by setting the base URL with https? Which other possibilites do I have?
I used
config {
baseURL = https://domain.com
}
and adapted all links which had a http in the beginning (otherwise the slider stopped working because Chrome didn't load the other ressources ...). Seems to work now.
Why doesn't embedding google fonts work on Heroku?
For example:
<link href='http://fonts.googleapis.com/css?family=<some_kinda_font>' rel='stylesheet' type='text/css'>
EDIT: turns out it works, one of my chrome extensions was blocking it as an "insecure script"
I discovered that heroku sets security parameters for using the google fonts url. It wants to use the https instead of plain http. Here's what worked for me.
Instead of:
#import url('http://fonts.googleapis.com/css?family=Oswald:400,700,300');
I used
#import url('//fonts.googleapis.com/css?family=Oswald:400,700,300');
If you notice the second line leaves out the http, allowing heroku to use https. I'm assuming you could probably use https in the link if you wanted to.
Simply use HTTPS instead of HTTP:
<%= stylesheet_link_tag "application", 'https://fonts.googleapis.com/css?family=<font_name>', :media => "all" %>
Change link to HTTPS
<link href='https://fonts.googleapis.com/css?family=some_kinda_font' rel='stylesheet' type='text/css'>
A better approach is to leave off the protocol altogether and just start with '//'. The correct protocol (HTTP or HTTPS) will be used depending on server context
<link href='//fonts.googleapis.com/css?family=some_kinda_font'
rel='stylesheet' type='text/css'>
Or you can use the url without specifying the http protocol
<%= stylesheet_link_tag "application", '//fonts.googleapis.com/css?family=<font_name>', :media => "all" %>
With this both http and https work.
The #import generates blocking CSS, which causes a slower page load. Using an extra DNS lookup for your fonts makes this even worse. To improve performance I would swap #import with #font-face and host the fonts locally/on your own web server. You can download the fonts using the Google Fonts download helper.
IMPORTANT NOTE - Putting your company name in front of something that is released for free to the community is uncool (Google Fonts). Using this to create a 'free service' to track the behaviour of people online is even more uncool. Most people call this stealing (plagiary) and snooping. We tell our kids that this is bad. We (as web developers) should not facilitate this. We should NOT feed Google Fonts to our visitors. Just download these free fonts and serve them from your webserver. They (should) have nothing to do with Google. If you are the owner of any of these fonts, please prevent Google from hosting them. Stop facilitating mass surveillance. Thank you.