Vote #70594
完了Libravatar and Gravatar-compatible servers support
0%
説明
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 ...
journals
Could be done with a plugin.
--------------------------------------------------------------------------------
The Libravatar Gem might be useful:
https://rubygems.org/gems/libravatar
https://github.com/gugod/libravatar
--------------------------------------------------------------------------------
Is there any progress yet? IMHO it's an much more privacy respecting solution that should be introduced upstream as gravatar is already?
--------------------------------------------------------------------------------
Upvoting this, I hate to be forced to have my face served by gravatar.com :/
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
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.
<pre><code class="yaml">
avatar_service_url: https://seccdn.libravatar.org
</code></pre>
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Thanks for promoting this again @Oliver :-)
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!
--------------------------------------------------------------------------------
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/'
--------------------------------------------------------------------------------
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!!
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
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/
--------------------------------------------------------------------------------
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.
!{width: 616px; border: 1px solid #ccc;}.text_avatar_server_config_html@2x.png!
--------------------------------------------------------------------------------
Nice addition.
--------------------------------------------------------------------------------
Committed the patch. Thank you all for suggesting this feature.
--------------------------------------------------------------------------------
Go MAEDA wrote:
> Committed the patch. Thank you all for suggesting this feature.
Awesome! Thanks a lot for your work!
Oliver
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Committed the fix for #31428 in r18192.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
related_issues
relates,Closed,31022,Always use HTTPS when accessing gravatar.com
blocks,Closed,31428,Gravatar can't be displayed when copy configration.yml.example to configration.yml
Admin Redmine さんが4年以上前に更新
- カテゴリ を Accounts / authentication_7 にセット
- 対象バージョン を 4.1.0_127 にセット