It's because the detection of https is made with request.ssl? which does not work with https managed by front proxies.

A fix in app/helpers/application_helper.rb :
<pre><code class="ruby">
def avatar(user, options = { })
if Setting.gravatar_enabled?
# The fix : checking if https is enabled in configuration
options.merge!({:ssl => (Setting.protocol == 'https'), :default => Setting.gravatar_default})
# options.merge!({:ssl => (request && request.ssl?), :default => Setting.gravatar_default})
email = nil
if user.respond_to?(:mail)
email = user.mail
elsif user.to_s =~ %r{<(.+?)>}
email = $1
end
return gravatar(email.to_s.downcase, options) unless email.blank? rescue nil
else
''
end
end
</code></pre>
--------------------------------------------------------------------------------
Using protocol relative URL (begins with two slash characters, e.g. //www.gravatar.com/avatar/... ) will resolve this issue. Please take a look at this patch: attachment:gravatar-protocol-relative-url.diff

Redmine don't have to know whether it is accessed via HTTPS or HTTP because web browsers choose appropriate protocol to access Gravatar.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
I am confirming this issue when running Redmine 3.2.0 with Passenger 5.0.22.

The protocol setting (Settings->General->Protocol) is ignored, because the logic in application_helper.rb is flawed.

The suggested patch in Note 1 above seems to work fine.
--------------------------------------------------------------------------------
Jérôme BATAILLE wrote:
> It's because the detection of https is made with request.ssl? which does not work with https managed by front proxies.
>
> A fix in app/helpers/application_helper.rb :
> [...]

The same "fix" was applied in r10184 and reverted soon after, see #9365 for more details.

I've committed the solution proposed by Go Maeda in r15245. Thanks.
--------------------------------------------------------------------------------
I see that this issue has been closed, but I want to mention that this problem persists into version 3.2.1. Apparently, the patch did not make it in to 3.2.1, which is unfortunate.

I will hand-edit the files for now, and anticipate the 3.2.2 release.

--------------------------------------------------------------------------------
I am confirming that the Go Maeda patch in r15245 resolves the issue.
--------------------------------------------------------------------------------
I need to take that back. I am now getting a full SSL connection, which is great. However, after applying that patch, Gravatars are no longer being displayed at all.

Is there something else I need to do?

--------------------------------------------------------------------------------
After clearing my browser's cache, all is fine! Gravatars are being properly displayed within a full SSL environment. There are no non-SSL components, so the site is considered fully secured.

Thank you.
--------------------------------------------------------------------------------
Ken Zalewski wrote:
> I see that this issue has been closed, but I want to mention that this problem persists into version 3.2.1. Apparently, the patch did not make it in to 3.2.1, which is unfortunate.
>
> I will hand-edit the files for now, and anticipate the 3.2.2 release.

As you can see, this issue is assigned to 3.3.0, and the fix was not included in 3.2.1
--------------------------------------------------------------------------------
Yes, I do see that now. I missed that when I was testing the 3.2.1 release.

I will anticipate the 3.3.0 release then. :-)

--------------------------------------------------------------------------------
We are on version 3.3.0.stable.15633 and the avatars are still pulled using HTTP.

I checked the code and the changes from r15245 are in there.

We are using a couple of plugins from redminecrm.com, could they be doing something that reverts this patch?
--------------------------------------------------------------------------------
Just in case somebody else is having this problem and gets here via Google:

We were missing

<pre>
proxy_set_header X-Forwarded-Proto $scheme;
</pre>

in our nginx config so redmine was not aware that the original request was HTTPS.

Added that and now the whole page is HTTPS again.
--------------------------------------------------------------------------------

relates,Closed,18911,check Setting.protocol when determining gravatar protocol
relates,Closed,9365,Gravatar don't utilize HTTPS