[PATCH] gitweb: Add support for gravatar-ssl

Subsystems: the rest

DORMANTno replies

3 messages, 2 authors, 2016-06-15 · open the first message on its own page

[PATCH] gitweb: Add support for gravatar-ssl

From: Chris West (Faux) <hidden>
Date: 2016-06-15 22:54:27

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

From: Giuseppe Bilotta <hidden>
Date: 2016-06-15 22:54:27

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

From: <hidden>
Date: 2016-06-15 22:54:27

On Thu, Aug 09, 2012 at 09:36:46PM +0200, Giuseppe Bilotta wrote:
Chris West (Faux) wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help