Defect #21855
closedGravatar get images over http instead https
0%
Description
Hello!
Our redmine works via https, in preferences https is set up. But gravatars still use http-image links.
Details in attached picture.
Your prompt reply will be highly appreciated!
Files
Related issues
Updated by Jérôme BATAILLE almost 9 years ago
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 :
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
Updated by Go MAEDA almost 9 years ago
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: 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.
Updated by Go MAEDA almost 9 years ago
- Related to Patch #18911: check Setting.protocol when determining gravatar protocol added
Updated by Go MAEDA almost 9 years ago
- Related to Defect #9365: Gravatar don't utilize HTTPS added
Updated by Ken Zalewski over 8 years ago
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.
Updated by Jean-Philippe Lang over 8 years ago
- Status changed from New to Closed
- Assignee set to Jean-Philippe Lang
- Resolution set to Fixed
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.
Updated by Ken Zalewski over 8 years ago
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.
Updated by Ken Zalewski over 8 years ago
I am confirming that the Go Maeda patch in r15245 resolves the issue.
Updated by Ken Zalewski over 8 years ago
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?
Updated by Ken Zalewski over 8 years ago
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.
Updated by Jean-Philippe Lang over 8 years ago
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
Updated by Ken Zalewski over 8 years ago
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. :-)
Updated by Helge Sychla about 8 years ago
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?
Updated by Helge Sychla almost 8 years ago
Just in case somebody else is having this problem and gets here via Google:
We were missing
proxy_set_header X-Forwarded-Proto $scheme;
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.