[PATCH] gitweb: Add support for gravatar-ssl

[PATCH] gitweb: Add support for gravatar-ssl

[Chris West (Faux)]

Teach gitweb to allow 'avatar' to be set to 'gravatar-ssl', switching
to the https://secure.gravatar.com url form, to avoid mixed content
warnings when serving gitweb over https, with gravatar enabled.
---

I'd alternatively propose always using the https:// form of the URL,
but it seems significantly slower, so it's probably best to let people
pick to continue using the insecure version.

 gitweb/gitweb.perl |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3d6a705..d70e8b8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -482,7 +482,7 @@ our %feature = (
 
 	# To enable system wide have in $GITWEB_CONFIG
 	# $feature{'avatar'}{'default'} = ['<provider>'];
-	# where <provider> is either gravatar or picon.
+	# where <provider> is either gravatar, gravatar-ssl or picon.
 	# To have project specific config enable override in $GITWEB_CONFIG
 	# $feature{'avatar'}{'override'} = 1;
 	# and in project config gitweb.avatar = <provider>;
@@ -1117,7 +1117,7 @@ sub configure_gitweb_features {
 	# if the provider name is invalid or the dependencies are not met,
 	# reset $git_avatar to the empty string.
 	our ($git_avatar) = gitweb_get_feature('avatar');
-	if ($git_avatar eq 'gravatar') {
+	if ($git_avatar eq 'gravatar' || $git_avatar eq 'gravatar-ssl') {
 		$git_avatar = '' unless (eval { require Digest::MD5; 1; });
 	} elsif ($git_avatar eq 'picon') {
 		# no dependencies
@@ -2079,7 +2079,10 @@ sub gravatar_url {
 	my $email = lc shift;
 	my $size = shift;
 	$avatar_cache{$email} ||=
-		"http://www.gravatar.com/avatar/" .
+		($git_avatar eq 'gravatar-ssl' ?
+			"https://secure" :
+			"http://www")
+		. ".gravatar.com/avatar/" .
 			Digest::MD5::md5_hex($email) . "?s=";
 	return $avatar_cache{$email} . $size;
 }
@@ -2093,7 +2096,7 @@ sub git_get_avatar {
 	$opts{-size} ||= 'default';
 	my $size = $avatar_size{$opts{-size}} || $avatar_size{'default'};
 	my $url = "";
-	if ($git_avatar eq 'gravatar') {
+	if ($git_avatar eq 'gravatar' || $git_avatar eq 'gravatar-ssl') {
 		$url = gravatar_url($email, $size);
 	} elsif ($git_avatar eq 'picon') {
 		$url = picon_url($email);
-- 
1.7.10

Re: [PATCH] gitweb: Add support for gravatar-ssl

[Giuseppe Bilotta]

Chris West (Faux) wrote:

> Teach gitweb to allow 'avatar' to be set to 'gravatar-ssl', switching
> to the https://secure.gravatar.com url form, to avoid mixed content
> warnings when serving gitweb over https, with gravatar enabled.
> ---
> I'd alternatively propose always using the https:// form of the URL,
> but it seems significantly slower, so it's probably best to let people
> pick to continue using the insecure version.

Rather than introducing a new, separate setting, wouldn't it be better
to have the gravatar URL be automatically decided based on the current
gitweb URL? (use the ssl gravar url when the current protocol is https,
and the standard http url otherwise)

Re: [PATCH] gitweb: Add support for gravatar-ssl

[git]

On Thu, Aug 09, 2012 at 09:36:46PM +0200, Giuseppe Bilotta wrote:
> Chris West (Faux) wrote:
> 
> > Teach gitweb to allow 'avatar' to be set to 'gravatar-ssl', switching
> > to the https://secure.gravatar.com url form, to avoid mixed content
> > warnings when serving gitweb over https, with gravatar enabled.
> > ---
> > I'd alternatively propose always using the https:// form of the URL,
> > but it seems significantly slower, so it's probably best to let people
> > pick to continue using the insecure version.
> 
> Rather than introducing a new, separate setting, wouldn't it be better
> to have the gravatar URL be automatically decided based on the current
> gitweb URL? (use the ssl gravar url when the current protocol is https,
> and the standard http url otherwise)

I don't believe it's possible to reliably detect this kind of thing (on
the server side), think ssl terminators / reverse proxies / etc.,
although you can probably get 99% of the way there, which might be good
enough.

An alternative would be to dump some JS on the page to convert the SSL
links to non-SSL links if the page hasn't been loaded over SSL
(according to the browser)?  Or do it the other way around and ignore
the mixed content warnings that ssl users with no javascript will see.

I'd rather just hardcode the https version than do anything with JS.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html