When I load my site with WWW.example.com the custom fonts will load.
But if I just enter domain.com (without www) the fonts wont load in IE or Firefox but will in Chrome.
All my CSS files links are absolute.
Has anyone else faced this issue?
Be careful of XSS restrictions. Since you didnt say I'm assuming your links go to www.example.com instead of example.com. Browsers are wary of requesting files from other domains. You can set it to request from /path/to/css.css instead of an absolute link.
This is because of CORS (which basically means that browsers will not request resources from a server b that did not send the original document (which instead came from a server a) specifying the request, UNLESS b specifies that it will take requests that originate from a resources).
See http://www.w3.org/TR/cors/ and http://enable-cors.org/
Related
Since I've been adding an ssl certificate today and everything worked out good i'm still facing one problem.
i'm having insecure http which makes the green bar on top of the page go away. I want all my content on my website to load from https.
<img href="http://...."></img>
Needs to go to a https link for my images. I know I could manually adjust them all but I'm using plugins which load their own content from http links. I tried .htaccess files and i am also using them to force https on my website. But img tags don't see to change their href link to https.
I know i could manually adjust them all but i'm using plugins which
load their own content from http links.
If you already know the above restriction, the the following requirement would never be satisfied.
I'm having insecure http which makes the green bar on top of the page
go away.
The green bar is there because everything is being served over HTTPS, including your own calls, third-party plugins, any hidden frames/scripts/stylesheets etc.
You'll need to manually update your src="http:// (img tag uses src or srcset attribute and not href) links to point to https URLs. Even if your htaccess is set to forward HTTP calls to HTTPS, the browser sees an HTTP link, and turns your green bar to yellow (or red)!
I have a site which is completely on https: and works well, but, some of the images served are from other sources e.g. ebay, or Amazon.
This causes the browser to prompt a message: "this website does not supply identity information"
How can I avoid this? The images must be served from elsewhere sometimes.
"This website does not supply identity information." is not only about the encryption of the link to the website itself but also the identification of the operators/owners of the website - just like it actually says. For that warning (it's not really an error) to stop, I believe you have to apply for the Extended Validation Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificate. EVC rigorously validates the entity behind the website not just the website itself.
Firefox shows the message
"This website does not supply identity information."
while hovering or clicking the favicon (Site Identity Button) when
you requested a page over HTTP
you requested a page over HTTPS, but the page contains mixed passive content
HTTP
HTTP connections generally don't supply any reliable identity information to the browser. That's normal. HTTP was designed to simply transmit data, not to secure the data it transmits.
On server side you could only avoid that message, if the server would start using a SSL certificate and the code of the page would be changed to exclusively use HTTPS requests.
To avoid the message on client side you could enter about:config in the address bar, confirm you'll be careful and set browser.chrome.toolbar_tips = false.
HTTPS, mixed passive content
When you request a page over HTTPS from a site which is using a SSL certificate, the site does supply identity information to the browser and normally the message wouldn't appear.
But if the requested page embeds at least one <img>, <video>, <audio> or <object> element which includes content over HTTP (which won't supply identity information), than you'll get a so-called mixed passive content * situation.
Firefox won't block mixed passive content by default, but only show said message to warn the user.
To avoid this on server side, you'd first need to identify which requests are producing mixed content.
With Firefox on Windows you can use Ctrl+Shift+K (Control-Option-K on Mac) to open the web console, deactivate the css, js and security filters, and press F5 to reload the page, to show all the requests of the page.
Then fix your code for each line which is showing "mixed content", i.e. change the appropriate parts of your code to use https:// or, depending on your case, protocol-relative URLs.
If the external site an element is requested from doesn't use a SSL certificate, the only chance to avoid the message would be to copy the external content over to your site so your code can refer to it locally via HTTPS.
* Firefox also knows mixed active content, which is blocked by default, but that's another story.
Jürgen Thelen's answer is absolutely correct. If the images (quite often the case) displayed on the page are served over "http" the result will be exactly as described no matter what kind of cert you have, EV or not. This is very common on e-commerce sites due to the way they're constructed. I've encountered this before on my own site AND CORRECTED IT by simply making sure that no images have an "http" address - and this was on a site that did not have an EV cert. Use the ctrl +shift +K process that Jürgen describes and it will point you to the offending objects. If the path to an object is hard coded and the image resides on your server (not called from somewhere else) simply remove the "http://servername.com" and change it to a relative path instead. Correct that and the problem will go away. Note that the problem may be in one of the configuration files as well, such as one of the config.php files.
The real issue is that Firefox's error message is misleading and has nothing to do with whether the SSL is an EV cert or not. It really means there is mixed content on the page but doesn't say that. A couple of weeks ago I had a site with the same problem and Firefox displayed the no-identity message. Chrome, however, (which I normally don't use) displayed an exclamation mark instead of a lock. I clicked on it and it said the cert was valid (with a green dot), it was a secure connection (another green dot), AND had "Mixed Content. The site includes HTTP resources" which was entirely accurate and the source of the problem (with a red dot). Once the offending paths were changed to relative paths, the error messages in both Firefox and Chrome disappeared.
For me, it was a problem of mixed content. I forced everything to make HTTPS requests on the page and it fixed the problem.
For people who come here from Google search, you can use Cloudflare's (free) page rules to accomplish this without touching your source code. Use the "Always use HTTPS" setting for your domain.
You can also transfrom http links to https links using url shortener www.tr.im. That is the only URL-shortener I found that provides shorter links through https.
You just have to change it manually from http://tr.im/xxxxxx to https://tr.im/xxxxxx.
As per the guidelines to speed up site, I have off-loaded all my static content (JS|CSS|IMAGES) to a subdomain static.example.com.
The site is working fine but the problem arises when I load the secure pages. Browser throws a warnings for "InsecureContent" being loaded into my page.
We have ssl for only root domain not subdomain. I can't get another one but want to handle it this way. As the subdomain folder can be accessed inside the root folder i want this.
I want to handle this with .htaccess this way ->
When referer is https ://www.example.com/anything.php
Rewrite http ://static.example.com/folder/file.ex to https ://www.example.com/static/folder/file.ex
Somebody help me doing this.
Not going to help at all. In order for anything inside an htaccess file to get processed, the request has to have been received by the webserver. When your browser pops up the "Insecure Content" warning, it hasn't sent the request yet. This warning pops up when negotiating the SSL connection, and in your case, your cert doesn't cover the domain the request is being made to. That means adding any sort of redirect on the server's end isn't going to help. You're still going to see the warning.
You need to ensure that your content points to http://static.example.com/ somehow, by either using a relative URI base or maybe absolute URLs that explicitly point to http://.
Another option may be to use some kind of javascript on the client side.
I'm having a problem with a clients magento site that has https enabled on the secure pages,
The website it built heavily around static block content and on the https pages images are pulled from static blocks (over 400 of them) using the media insert in the static block {{media url="media/bla/bla/bob.png"}} these images are comign through as http://site.com/media/bla/bla/bob.png
its not realistic, and it wouldn't make any sense to go through and change all these links to direct links.
Any ideas?
Cheers
Roly!
You are suppose to use the {{store url=""}} or the {{secure_base_url}}media/ in ur blocks
if ur not certain that ur page will be on HTTPS or HTTP the use first one if you know for sure that the request will be HTTPs use second one. (NOTE. Second is a system config path not the actual value that u'll put in the CMS block).
Hope it helps.
Whereas media files are not subject to a fallback, and with the awareness that if the directory level for Magento changes w/r/t the webroot (e.g. http://site.com/ vs. http://site.com/magento/) you can lead with the double-slash network location:
<img src="//media/bla/bob.png" />
Therefore, a search and replace against using the current data in cms_block.content is indicated.
I'll reiterate that this is not appropriate for skin assets due to the fallback.
I've just got a site running nicely with the whole site running through SSL, but Google Chrome is throwing a "This page contains some insecure elements" message, which isn't good in terms of end user trust-ability. All other browsers work fine, and give the golden padlock.
The site is a Drupal 6 e-commerce site, running on apache2, and the error appears in the front end as well as the admin area.
Does anyone know of any methods to find out exactly which elements are being considered insecure?
Edit: I've used Fiddler to check the traffic, and it really is all HTTPS. It even complains on the site holding page, which is very light and has no javascript etc on it...
It could be a browser issue? Have you tried restarting, or clearing all of your cache?
In Chrome, this is trivial. Hit ctrl+shift+j to open the developer tools, and it will plainly list the URL of the insecure content.
Try it on https://www.fiddler2.com/test/securepageinsecureimage.htm, for instance.
I just had a similar problem. Turns out it was a hardcoded background image URL in a CSS file.
You should particularly check any 3rd party stylesheets you are using, as they may hotlink to an image on another server.
Easy solution? Save those images to your server and change the URLs to relative paths in the CSS file.
Hope this helps!
Search the source for http:? Something like <Ctrl-U> <Ctrl-F> http: in firefox should do.
The insecure element is something loaded over insecure — non-https — connection, e.g. image, stylesheet, etc. you obviously need fully qualified URL to load insecure element/
Use Firebug plugin of Firefox. In the NET tab all file locations are shown clearly. Try to find any files that are obtained from http protocol.
It's probably related to this bug:
http://code.google.com/p/chromium/issues/detail?id=24152
Which is why a restart fixed it.