Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
jpamental CreditAttribution: jpamental commentedOK - 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):
Thanks again!
Jason
Comment #2
sreynen CreditAttribution: sreynen commentedSounds 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.
Comment #3
sreynen CreditAttribution: sreynen commentedI'm going to mark this as a bug, as I expect the security notices in IE make it unusable for some sites.
Comment #4
jpamental CreditAttribution: jpamental commentedYou'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)
Comment #5
sreynen CreditAttribution: sreynen commentedFix committed in both D7 and D6 dev.
Comment #7
jccc CreditAttribution: jccc commentedIt'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>';
Comment #8
sreynen CreditAttribution: sreynen commentedCan 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.
Comment #9
sreynen CreditAttribution: sreynen commentedI 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?
Comment #10
sreynen CreditAttribution: sreynen commentedI'm closing this for now. If anyone is having a problem with this, please re-open.
Comment #11
Daeluin CreditAttribution: Daeluin commentedHmmm. 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?
Comment #12
sreynen CreditAttribution: sreynen commentedDaeluin, 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.
Comment #13
sreynen CreditAttribution: sreynen commentedClosing again. As always, please re-open if you're still having a problem and can offer details.
Comment #14
Daeluin CreditAttribution: Daeluin commentedSorry, 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....
Comment #15
sreynen CreditAttribution: sreynen commentedOkay, 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.
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous commentedAs 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.
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedSo, 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.
Comment #18
sreynen CreditAttribution: sreynen commentedIf $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']?
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.
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commentedAs 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.
Comment #20
sreynen CreditAttribution: sreynen commentedSince 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.
Comment #21
steven.wichers CreditAttribution: steven.wichers commentedFYI protocol less URLs can help http://stackoverflow.com/questions/4831741/can-i-change-all-my-http-link...
Comment #22
sreynen CreditAttribution: sreynen commentedI'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.
Comment #23
Anonymous (not verified) CreditAttribution: Anonymous commentedFor 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';
Comment #24
mstrelan CreditAttribution: mstrelan commentedI'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 ifHTTP_X_FORWARDED_SSL
is on. Unfortunately however it didn't seem to help for loading Fontdeck font via fontyourface.Comment #25
pivwani CreditAttribution: pivwani commentedThe 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"