I'm using Seven for the admin theme and still getting only a partially encrypted page. (I enabled Garland to test and it's partially encrypted too) The non-admin portion of the site is using a custom theme and partially encrypted; I figure troubleshooting an admin page with Seven will be a good start.

I have css & javascript compression enabled - doesn't that make all those paths relative? When I look at the page source there are 4 css files and 3 javascript, all being served from sites/default/files (then css or js).

There is some jquery.extend stuff in but all the paths in it are relative. There are no images on the page.

I guess the main question is if css & js compression is enabled, whether that makes all the paths relative and if not, how to troubleshoot? Thanks.

Comments

crystaldawn’s picture

crystaldawn commented

No, compression does not change any coding such as paths. All it does is strip out white space and make the file extremely difficult to read. It helps speed up the transfer of very large js/css files. If you have http:// ANYWHERE on your page, any modern browser will report it as "unsecured". The most common culprits are src tags for images, css files, and js files. You want to make them relative, you dont want to give them full URLs. Once you get them to relative paths, your unsecured errors will disappear.

Bricks and Clicks Marketing’s picture

Bricks and Clicks Marketing
Location Durham, NC
commented

OK - but Garland is known to be all relative and it was unsecured as well (when I was checking /admin, with no blocks or content of any sort and the theme logo in use). I'm guessing Seven should be ok too, but I'll turn off compression and see what I can find.

Bricks and Clicks Marketing’s picture

Bricks and Clicks Marketing
Location Durham, NC
commented

Geez - I removed all the http:// that I could find and all that's left is this (generated by $head):

<meta name="generator" content="Drupal 7 (http://drupal.org)" />

this in the Google Analytics script:

"http://www"

and some links to Tweets. I've removed them all (so $head is now gone & the GA module is off) and the page (www.eye-hole.com/cart) is still partially encrypted. There is no http:// *anywhere* on the page.

There are links to a google webfont & html5 shiv but both start with //. I've removed those just to see and the page is *still* only partially encrypted. All the images on the page have relative urls, and links to outside sites like Facebook go to relative url (/facebook) that is redirected when someone goes to the url.

I'm stumped - what else could it be?

Bricks and Clicks Marketing’s picture

Bricks and Clicks Marketing
Location Durham, NC
commented

Can you suggest anything else? This is the final thing holding up an ecommerce site from launching.

Bricks and Clicks Marketing’s picture

Bricks and Clicks Marketing
Location Durham, NC
commented

There is something very much amiss - I switched the admin theme to Garland and the *only* http:// on the page is

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
  "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" version="XHTML+RDFa 1.0" dir="ltr"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:dc="http://purl.org/dc/terms/"
  xmlns:foaf="http://xmlns.com/foaf/0.1/"
  xmlns:og="http://ogp.me/ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:sioc="http://rdfs.org/sioc/ns#"
  xmlns:sioct="http://rdfs.org/sioc/types#"
  xmlns:skos="http://www.w3.org/2004/02/skos/core#"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema#">

<head profile="http://www.w3.org/1999/xhtml/vocab">

All the other links on the page either start with https:// or they are relative. All extraneous blocks have been removed on admin pages, leaving just a core menu block & a core user block. The page is *still* only partially encrypted. I'm guessing that it must be something within one of the javascripts being linked to?

Bricks and Clicks Marketing’s picture

Bricks and Clicks Marketing
Location Durham, NC
commented
Status: Active » Closed (fixed)

Found the offender - a Google fonts link in a CSS file.

Bricks and Clicks Marketing’s picture

Bricks and Clicks Marketing
Location Durham, NC
commented
Issue summary: View changes

added info on SSL/settings.php config

bennotron’s picture

bennotron commented
Issue summary: View changes

Even a single "http://" link, even in a referenced CSS file, will cause this "partial encryption"? What garbage! Having a link to an external or internal site on a page that is not secure does not make my site less secure! I I were to take a "fort knox" website, encrypted seven ways til Sunday and then put a link to google on the bottom, this presents no danger, other than the fact that my site isn't responsible for what you find at google. I'm chasing this down, just having switched over to SSL connected auth, but if I have to scour the entire site, all links, all css files, all code in general to eliminate http:// from every reference to anything, I might as well switch back.

crystaldawn’s picture

crystaldawn commented
Issue summary: View changes

Do not change the summary with info to suit yourself unless you are the original author or are making updates that effect a solution (patch files/instructions, etc).

As for the SSL insecure issues, ANY resource that has http:// is a problem no matter if it's a css/js file hosted elsewhere or a lowly image. Insecure is insecure. There are many links explaining why browsers will complain about those types of insecure items being on the page. Enabling Aggregation (not compression) will help but its NOT going to change hardcoded absolute paths which is usually the cause of issues like this.

So enable aggregation first, that will take care of a few possibilities. Then whatever is left over are almost always (90-95% of the time) going to be hardcoded absolute paths. This is why using Relative paths is such a critical rule to follow.