Project

General

Profile

Actions

Feature #9112

closed

Libravatar and Gravatar-compatible servers support

Added by Jim Cheetham about 13 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Accounts / authentication
Target version:
Start date:
2011-08-24
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

As an alternative to gravatar support, could we have libravatar support as well?

http://libravatar.org/ provides the same sort of service as Gravatar, but instead of forcing you to host your data on a central service, allows federation out to multiple servers -- so you could have automatic support for fallthrough to one set of images for internal company use, another for official external use, or images hosted on libravatar.org itself, with additional fallback onto gravatar as well ...


Files


Related issues

Related to Redmine - Patch #31022: Always use HTTPS when accessing gravatar.comClosedGo MAEDA

Actions
Blocked by Redmine - Defect #31428: Gravatar can't be displayed when copy configration.yml.example to configration.ymlClosedGo MAEDA

Actions
Actions #1

Updated by Etienne Massip about 13 years ago

  • Category set to Third-party libraries

Could be done with a plugin.

Actions #3

Updated by n ext over 9 years ago

Is there any progress yet? IMHO it's an much more privacy respecting solution that should be introduced upstream as gravatar is already?

Actions #4

Updated by Sandro Santilli over 7 years ago

Upvoting this, I hate to be forced to have my face served by gravatar.com :/

Actions #5

Updated by Oliver Falk over 5 years ago

Hi!

Libravatar has been recently completely renewed and now shines again.

Changing from Gravatar to Libravatar is only a matter of changing the "base URL". It's completely compatible with Gravatar. The default even is to proxy to Gravatar. With proxy I mean, real proxying; Gravatar doesn't see the client IP and therefore preserving user privacy.

This is really low hanging fruit, as you do not really need to change the module you use, if this is too much work. You just need to replace the URL.

https://secure.gravatar.com/ => https://secure.libravatar.org/

Thanks and kind regards,
Oliver

Actions #6

Updated by Go MAEDA over 5 years ago

What do you think about the attached patch?

The patch introduces a new configuration option "avatar_service_url". You can switch to Libravatar by setting the option in the configuration.yml file like this.

  avatar_service_url: https://seccdn.libravatar.org
Actions #7

Updated by Oliver Falk over 5 years ago

Hi!
In principle I like this! If I may suggest: Put it the other way round and make Libravatar the default :-)
I doesn't change anything for the user/admin, except they'll have better privacy.

Actions #8

Updated by Go MAEDA over 5 years ago

  • Category changed from Third-party libraries to Accounts / authentication
  • Target version set to Candidate for next major release
Actions #9

Updated by Jim Cheetham over 5 years ago

Thanks for promoting this again Oliver Cordero :-)

The patch as presented gives the admin the option to easily select their own service, which is excellent.

We still have a hard-coded portion, '/avatar/' + hash, and this should be surfaced in the documentation at least, and probably in the configuration file as well. But to be fair, this is the published API for both Libravatar and Gravatar, and is probably just as static as the formation of the hash itself. It's been correct for many years now ...

The argument of which should be the default is going a step further than I was asking for, and whereas 7 years ago I was happy for this to be just an option these days I think more people are sensitive to privacy concerns. However, technically this patch provides good capability, and I'm happy to see it moving on.

Of course I now wish I'd dug in to the code myself all those years ago and written the patch myself!

Actions #10

Updated by Go MAEDA over 5 years ago

Updated the patch. Now it includes test code.

Jim Cheetham wrote:

We still have a hard-coded portion, '/avatar/' + hash, and this should be surfaced in the documentation at least, and probably in the configuration file as well.

I have described what URLs are generated in configuraition.yml.example. Thank you for reviewing the patch.

But to be fair, this is the published API for both Libravatar and Gravatar, and is probably just as static as the formation of the hash itself. It's been correct for many years now ...

I think hard-coding '/avatar/' is OK because DNS-based server discovery mechanism described on https://wiki.libravatar.org/api/ assumes that the path is always '/avatar/'

Actions #11

Updated by Oliver Falk over 5 years ago

Hi!

Yes, hardcoding /avatar/ should be fine. I'm pretty sure all services are using this path in order to be compatible with Gravatar. If - for some reason - someone has a different path with his service, he needs to rewrite it in the web server configuration accordingly - not really our issue.
Glad you enhanced the code with tests.
I would still love to see Libravatar be the default or some way how we could potentially encourage users to switch to Libravatar if it's not the default - but it is your decision and not mine of course.

Thanks for your work on this - highly appreciated!!

Actions #12

Updated by Go MAEDA over 5 years ago

  • Target version changed from Candidate for next major release to 4.1.0

Oliver Falk wrote:

I would still love to see Libravatar be the default or some way how we could potentially encourage users to switch to Libravatar if it's not the default - but it is your decision and not mine of course.

I don't think we should make Libravatar the default because most people probably use Gravatar instead of Libravatar. In addition, I have doubts about the continuity of libravatar.org (see the articles below).
https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-09-01/
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/

Anyway, supporting Gravatar-compatible servers including Libravatar is easy, and I think it is valuable because it gives users another choice. I am setting the target version to 4.1.0.

Actions #13

Updated by Oliver Falk over 5 years ago

Hi!

I don't think we should make Libravatar the default because most people probably use Gravatar
instead of Libravatar.

By default Libravatar proxies to Gravatar and therefore it doesn't make any difference to the user, apart from more privacy, since Gravatar only sees the proxy address.

In addition, I have doubts about the continuity of libravatar.org (see the articles below).
https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-09-01/
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/

I know those articles. I'm basically the reason behind the 'is not going away'. Software has been rewritten by me and is now hosted on Fedora Infrastructure - so really no doubts if it's staying or not. It IS staying. ;-)

Oliver

Actions #14

Updated by Go MAEDA over 5 years ago

  • Related to Patch #31022: Always use HTTPS when accessing gravatar.com added
Actions #15

Updated by Go MAEDA over 5 years ago

Updated the patch. I have changed the config name from avatar_service_url to avatar_server_url because users may use their own avatar server instead of services such as Gravatar and Libravatar.

You can see the list of opensource Gravatar-compatible servers: https://wiki.libravatar.org/running_your_own/

Actions #16

Updated by Go MAEDA over 5 years ago

Added a message about the avatar server configuration on the settings page. Users will have a chance to know by this message that the avatar server is configurable.

Actions #17

Updated by Marius BÄ‚LTEANU over 5 years ago

Nice addition.

Actions #18

Updated by Go MAEDA over 5 years ago

  • Status changed from New to Closed
  • Assignee set to Go MAEDA
  • Resolution set to Fixed

Committed the patch. Thank you all for suggesting this feature.

Actions #19

Updated by Oliver Falk over 5 years ago

Go MAEDA wrote:

Committed the patch. Thank you all for suggesting this feature.

Awesome! Thanks a lot for your work!

Oliver

Actions #20

Updated by Go MAEDA over 5 years ago

  • Status changed from Closed to Reopened
Actions #21

Updated by Go MAEDA over 5 years ago

  • Blocked by Defect #31428: Gravatar can't be displayed when copy configration.yml.example to configration.yml added
Actions #22

Updated by Go MAEDA over 5 years ago

  • Status changed from Reopened to Closed

Committed the fix for #31428 in r18192.

Actions #23

Updated by Go MAEDA about 5 years ago

  • Subject changed from Libravatar support to Libravatar and Gravatar-compatible servers support
Actions

Also available in: Atom PDF