Hi-

One issue that's come up is when pages are HTTPS, there's a security warning because the JS is referencing the script via HTTP instead of HTTPS. I know that Typekit and Fonts.com both support HTTPS (I'm sure others do as well) - I tried adding this but didn't have any luck with it doing anything:


        if($_SERVER['HTTPS']) {
        	$typeHost = 'https:';
        } else {
        	$typeHost = 'http:';
        }
        $script = '<script type="text/javascript" src="'. $typeHost . '//fast.fonts.com/jsapi/' . $project . '.js"></script>';

(this was added in the fonts_com.module)

Any ideas why it wouldn't do anything?

Thanks!

Jason

Comments

jpamental’s picture

jpamental CreditAttribution: jpamental commented

OK - my bad. It is working - I was just checking the wrong server (DOH)

So I'd change this to a feature request - it would be great to add this to both the fonts_com.module and typekit module (at least):


        if($_SERVER['HTTPS']) {
        	$typeHost = 'https:';
        } else {
        	$typeHost = 'http:';
        }
        $script = '<script type="text/javascript" src="'. $typeHost . '//use.typekit.com/' . $kit . '.js"></script>';

Thanks again!

Jason

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Version: 6.x-2.6 » 7.x-1.x-dev

Sounds good. The Google provider already does this, but I didn't think to check if HTTPS was an option on the other providers. I'll add this to the D7 version first.

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Category: support » bug

I'm going to mark this as a bug, as I expect the security notices in IE make it unusable for some sites.

jpamental’s picture

jpamental CreditAttribution: jpamental commented

You're right - it does (that's actually what pushed it to the front burner)

Thanks!

Jason

(once I get the hang of D.O and Git I'll be better at creating patches properly)

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Status: Active » Fixed

Fix committed in both D7 and D6 dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jccc’s picture

jccc CreditAttribution: jccc commented
Version: 7.x-1.x-dev » 6.x-2.8
Status: Closed (fixed) » Needs review

It's my understanding that caching can fudge this if you check $_SERVER['HTTPS'] in the module. Shouldn't we do it client-side the way Google does it?

$script = '<script type="text/javascript">var protocol = (("https:" == document.location.protocol) ? "https://" : "http://");document.write(unescape("%3Cscript src=\'" + protocol + "use.typekit.com/' . $kit . '.js\'%3E%3C/script%3E"));</script>';

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Status: Needs review » Postponed (maintainer needs more info)

Can you elaborate on what you mean by "caching can fudge"? I'm going to need a compelling argument to introduce a new JavaScript dependency.

Drupal's page cache uses $base_root, which is set by drupal_settings_initialize(), which checks $_SERVER['HTTPS']. So the HTTP and HTTPS versions of a given page should get cached separately.

sreynen’s picture

sreynen CreditAttribution: sreynen commented

I asked a few people about caching with HTTPS, and found out the most likely problem is with caching in front of Drupal. But Drupal core uses $_SERVER['HTTPS'] to determine local CSS and JS addresses, so it's a problem with core itself. Apparently some people solve this by altering the value $base_url in settings.php. If this is a common solution, we should just check that instead of $_SERVER['HTTPS']. I'd really like to solve against some actual problems rather than a hypothetical problem, though, to make sure the solution makes sense.

If anyone is having the problem of $_SERVER['HTTPS'] not being set by proxy caches, how do you solve it for Drupal core?

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Component: Code » Code (general)
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I'm closing this for now. If anyone is having a problem with this, please re-open.

Daeluin’s picture

Daeluin CreditAttribution: Daeluin commented
Status: Closed (cannot reproduce) » Needs review

Hmmm. We have 2 sites using Google Fonts and HTTPS with securepages.

Both are reporting mixed mode warnings on https pages, which are coming from unencrypted Google Fonts URLs. We had been using fontyourface-6.x-2.0 and 6.x-2.10, both had the same issue. Both are now updated to 6.x-dev and still having the same issue.

From the above thread I thought this should be working, is there a setting I'm missing, or something that could be interfering?

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Version: 6.x-2.8 » 6.x-2.x-dev
Status: Needs review » Postponed (maintainer needs more info)

Daeluin, can you give an example of the specific font URL that is going over HTTP on HTTPS pages? Or if the site is online, can you point to an example? It should be working, and I don't have any ideas on why it wouldn't be.

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Closing again. As always, please re-open if you're still having a problem and can offer details.

Daeluin’s picture

Daeluin CreditAttribution: Daeluin commented
Version: 6.x-2.x-dev » 6.x-2.10
Status: Closed (cannot reproduce) » Needs review

Sorry, my notifications weren't set correctly, just saw this.

Here's an example, using 2.10, cache is cleared:
https://www.eallenboutique.com/bag

Chrome shows the error as:
The page at https://www.eallenboutique.com/bag displayed insecure content from http://themes.googleusercontent.com/static/fonts/alfaslabone/v2/Qx6FPcit....

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Status: Needs review » Closed (fixed)

Okay, that's a different issue. The problem is the CSS was built with HTTP URLs on a page over HTTP and cached, and that cache doesn't get rebuilt when you switch to HTTPS. That's beyond the scope of this issue, so I opened a new issue for it: #1551206: Some way to handle HTTP/HTTPS in CSS when switching between HTTP and HTTPS on site. I'm not sure if that's a problem we can solve in this module. I'll look into it, but it might need to be addressed in Secure Pages or whatever you're using to do the HTTP/HTTPS switching.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Version: 6.x-2.10 » 7.x-2.2
Status: Closed (fixed) » Active

As noted in #9, the solve for making core deal with this is to set the $base_url.

In my example:

httpd is listening on localhost port 8080.
varnish is listening on private port 8181.
pound is listening on public port 443 and public port 80.

Requests to public port 80 are redirected to public port 443.
Requests to public port 443 are directed to varnish on private port 8181.
Requests to private port 8181 are passed on to httpd on 8080 if the request cannot be handled by the cache.

Since httpd is listening on port 8080, $_SERVER['HTTPS'] is not true.

I have not dug into the code yet, however, I will attempt to do so and provide a workable patch.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

So, no patch because this is a complete hack and there is likely a better way to do this, however....

I added a checkbox to the typekit form:

'typekit_api_https' => array(
'#type' => 'checkbox',
'#title' => t('Use HTTPS URLs'),
'#description' => t('If checked, TypeKit URLs will use HTTPS instead of HTTP.'),
'#default_value' => variable_get('typekit_api_https', 0),
),

And save the value in the submit function:

variable_set('typekit_api_https', $form_state['values']['typekit_api_https']);

And use that to check for HTTPS in the preprocess function:

if (variable_get('typekit_api_https', 0) == 1) {
$base = 'https://use.typekit.com/';
} // if

This should probably be a global setting instead of limited to just the typekit API as I have here.

sreynen’s picture

sreynen CreditAttribution: sreynen commented

As noted in #9, the solve for making core deal with this is to set the $base_url

If $base_url is the solution in core, why not use it as the solution here? I don't understand why this would be a configuration option when no one has mentioned a need to configure it. Everything discussed here was about automatically switching, and it looks like $base_url is a reliable trigger for that switching, so why not just use it instead of $_SERVER['HTTPS']?

In my example:

Is this a real setup you could test on, or just something that might happen? I'd like to test this on a real setup.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

As this is a production system, I went with the option which I knew I could implement the quickest and guarantee would work. I chose the configuration option as this gives more control to the site admin when deciding how to load the font. Specifically, I can see the possibility of a use case existing whereby the site admin wants to use https for the external loads, even on non-https pages.

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Status: Active » Needs work

Since cross-loading HTTP and HTTPS content throws a security warning in some browsers, and avoiding that is the reason this issue was created, I'm going to call that out of scope for this issue and focus on correctly switching the protocol of font references to match the protocol of the current page. If someone actually wants cross-loading, let's talk about that in a separate issue.

steven.wichers’s picture

steven.wichers CreditAttribution: steven.wichers commented

FYI protocol less URLs can help http://stackoverflow.com/questions/4831741/can-i-change-all-my-http-link...

sreynen’s picture

sreynen CreditAttribution: sreynen commented
Status: Needs work » Closed (fixed)

I'm not sure why I marked this as "needs work" in #20. I believe the original issue is fixed and anything additional (like intentionally cross-loading HTTP and HTTPS) should be handled in separate issues.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Version: 7.x-2.2 » 7.x-2.6

For anyone who comes across this in the future, the best workaround when serving content in the manner described in 16, is to append the following to your settings.php file:

$_SERVER['HTTPS'] = 'on';

mstrelan’s picture

mstrelan CreditAttribution: mstrelan commented

I've also just found the SSL Proxy module which you can install to tell Drupal that you're using a proxy to serve content over HTTPS. This simply sets $_SERVER['https'] = 'on'; when it's appropriate, for example if HTTP_X_FORWARDED_SSL is on. Unfortunately however it didn't seem to help for loading Fontdeck font via fontyourface.

pivwani’s picture

pivwani CreditAttribution: pivwani commented
Issue summary: View changes

The most effective way to remove this error is to add

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

to the <head> of every page. You can edit your tpl file or use the module "add to head"