* Add additional documentation and warnings to the WEB_DOMAIN setting.
This feature is largely undocumented, and quite a number of users have
shot them in the feet already despite the warning. Added a bit of documentation
and expanded the warning until we have a mechanism for dealing with conflicting
user URIs.
* Change WEB_DOMAIN comments to point to the extensive online documentation
This provides a hotfix for outbound salmon requests to other Mastodon instances
as they currently will try to resovle user@WEB_DOMAIN instead of user@LOCAL_DOMAIN
(see #2012 and #20312).
Furthermore, this should ease transition from users switching from
LOCAL_DOMAIN = WEB_DOMAIN to another LOCAL_DOMAIN when WEB_DOMAIN does not change.
* Refresh local info for remote accounts when webfinger returns new values
It only refreshes account info if one of the URLs or the public-key changes,
in which cases it refreshes the full info, re-downloading the feeds from that
user.
Some special handling should probably be done when the public key changes,
but I have been unable to find any use for it in Mastodon yet.
* Re-fetch remote users we aren't subscribed to.
This might induce performance issues, we might want to only do that for users
we explicitly attempted to subscribe but failed to.
* Refactor changes
* Do not refresh existing remote account details more than once a day
* Avoid re-fetching webfinger info in tests unless otherwise specified
* Allow running mastodon on a different domain as the one used for identifying users
* Alter documentation of WEB_DOMAIN to make clear it shouldn't be used unless the admin knows what they are doing
* Compare to web_domain instead of local_domain when dealing with feeds/API
* Correctly identify mentions to local accounts
Mentions URLs point to the person's web profile, i.e., the user page served on WEB_DOMAIN.
The goal of this change is to enhance Mastodon's handling of remote domains
for which the APIs reside on a different host (see issue #1032).
Indeed, when a remote user unknown to Mastodon is mentionned, only its profile
URL (e.g. https://social.example.org/users/User) is known, and Mastodon has to
build a @username@domain handle for it. To do so, Mastodon fetches the user's
atom feed (e.g., https://social.example.org/users/User.atom) and uses its
content to get the username part of the handle, and the URL's host part to
build the domain (e.g., @User@social.example.org). This handle is then used
for a Webfinger request.
In the case where example.org serves the Webfinger info for @User@example.org
and all feeds and APIs are hosted at social.example.org, Mastodon will still
build @User@social.example.org and fail at resolving the account's details
through Webfinger.
This patch changes this behaviour by using the author's email address from
the atom feed to build the handle. In Mastodon-generated atom feeds, the
email address is always the handle it expects for federation.
ThibGandEugen Rochko