-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle webfinger 301 #171
Comments
If the issue here is only figuring out and caching which domains have a WebFinger endpoint then fedifinder just needs to request $DOMAIN/.well-known/webfinger. A 400 answer means that the domain does speak WebFinger, a 404 means that it does not and anything else is an implementation error (for which some heuristics could be developed or not, depending how much you care about buggy implementations). |
I don't think that in particular is the issue at all. It is merely a means to discover a relatively common setup of Mastodon that currently displays an error in Fedifinder. Handling only 400 and 404 and calling everything else an implementation error may be technically correct, but again, the usage of 301 is advised by the Mastodon docs to support one of their features, they're the most prominent Fediverse player, and the reason most people use this particular tool. |
Sure: first thing redirects must be followed (RFC 7033 section 4.2), then the status will tell if that is an actual WebFinger endpoint. |
This will break in some situations. If you query the WebFinger for @[email protected] , it redirects to https://mastodon.org.uk/.well-known/webfinger?resource=acct:[email protected] - but if you check for https://bairwell.com/.well-known/webfinger/ (or @[email protected] or any "unrecognised" user), you'll get a 400 error (code is from https://www.jwz.org/blog/2022/11/using-your-own-domain-as-a-mastodon-handle/ ) |
Related to #166 but not exactly the same.
My Mastodon handle is
@[email protected]
. My private mastodon instance runs atmastodon.chainfire.eu
. Fedifinder returns:This happens for a bunch of people in my list, and I think for the same reason.
As I understand from the other issue, Fedifinder checks
/.well-known/host-meta
and/.well-known/nodeinfo
which the shortchainfire.eu
domain does not handle (404). Unlike #166, the short domainchainfire.eu
doesn't actually handle/.well-known/webfinger
either, but it does 301 permanently redirects it to the long domainmastodon.chainfire.eu
, which also serves thehost-meta
andnodeinfo
URLs:While it would be trivial for me to redirect
@chainfire
,host-meta
andnodeinfo
as well, I believe this should be handled by Fedifinder, for the simple reason that mine is a simple setup outlined by the Mastodon official documentation, that many other private hosters will be following as well. See the docs,LOCAL_DOMAIN
andWEB_DOMAIN
options, and see the sample nginx adjustment, which I have used verbatim.I have not looked at your code, and I understand from the other issue there is a cache issue at play, but I would suggest something like this:
host-meta
andnodeinfo
as usual on the suspected domainwebfinger
(without query parameters) performs a 301 to a different domainhost-meta
andnodeinfo
on the new domainThis domain remap can be cached for all users of that domain, as 301 is intentionally a permanent move. I am not absolutely sure if a 301 is allowed to vary by query parameters or how browsers normally handle that, but I would suggest that the case where it does not vary by query parameters is significantly more common (due to it being the official Mastodon docs way) than where it does (which would be a completely custom implementation). So the outlined change would give the expected result for most cases.
Thank you for your work, I hope this can be implemented.
EDIT: Updated docs link to the relevant anchor, wording, hopefully improved clarity
The text was updated successfully, but these errors were encountered: