XF 1.4 Gravatar not secure on our secure site - so padlock breaks

[Stuart Wright]

So we are properly TSL at https://www.avforums.com
Yet in XenForo/Template/Helper/Core.php

return (XenForo_Application::$secure ? 'https://secure' : 'http://www')
   . ".gravatar.com/avatar/{$md5}?s={$size}{$default}";

does not insert the secure call and the padlock is broken because of the http:// call to Gravatar.
We have to edit core.php to read

return "https://secure.gravatar.com/avatar/{$md5}?s={$size}{$default}";

Is this a problem with Xenforo or our server?

 

[AlexT]

Stuart, do have one or more SSL terminating reverse proxies in front of your XenForo installation? If that's the case, the webserver running XenForo might only be using HTTP, and that's when XenForo falsely assumes HTTP as well. You could hardcode HTTPS inside XenForo by modyifing (either through an addon or by patching) self::$secure inside XenForo_Application. Specifically, this is the relevant code:

self::$secure = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on');

 

[Stuart Wright]

Thank you. What is 'XenForo_Application' ? I.e. what do I have to modify?

 

[rainmotorsports]

Thank you. What is 'XenForo_Application' ? I.e. what do I have to modify?

Likely /library/Xenforo/Application.php

 

[AlexT]

Thank you. What is 'XenForo_Application' ? I.e. what do I have to modify?

Like @rainmotorsports said, it's /library/XenForo/Application.php. If you want to patch it, until someone may write a small addon for you, you can modify it as such.

Before:

self::$secure = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on');

The $_SERVER['HTTPS'] is set to a non-empty value if XenForo was queried through HTTPS. The expression thus is true and sets self::$secure true. However HTTPS is usually not the case if your server running XenForo is behind a reverse proxy, load balancer or similar that did previously the SSL termination. So force the variable to true so that XenForo doesn't have to rely on the (internal) server header.

After:

self::$secure = true;

I suppose it wouldn't be a bad idea to have a config option forcing HTTPS in cases like this.

 

[rainmotorsports]

@AlexT actually reading the line all he should need to do for the unmodified line to work in xenforo is to actually add the appropriate https line to the config right? Thats what it is looking for.

Oh nevermind its querying it from the server then... eek

 

[Mike]

He actually has the line in config.php, but it's too late -- the value is already loaded/calculated. The ideal way to do it is to pass the value from the web server. Apache will do it automatically if serving via SSL; Nginx can add it (http://blog.chrismeller.com/getting-php-https-detection-working-in-nginx).

 

[AlexT]

He actually has the line in config.php, but it's too late -- the value is already loaded/calculated. The ideal way to do it is to pass the value from the web server. Apache will do it automatically if serving via SSL; Nginx can add it (http://blog.chrismeller.com/getting-php-https-detection-working-in-nginx).

Assuming Stuart uses front servers for SSL termination and backend servers for running the applications, he should look at the X-Forwarded-Proto header (proxy_set_header X-Forwarded-Proto $scheme) which could then be used in combination with the fastcgi_param parameters Mike pointed at. See here: http://danconnor.com/post/4f65ea41daac4ed031000004/https_ssl_proxying_nginx_to_nginx

 

[Stuart Wright]

I've emailed my host directing him to this thread, thank you. We have NGINX, by the way.