Skip to content
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

[feature] Discover webfinger through host-meta #1588

Merged
merged 7 commits into from
Mar 8, 2023

Conversation

daenney
Copy link
Member

@daenney daenney commented Mar 4, 2023

Description

If this is a code change, please include a summary of what you've coded, and link to the issue(s) it closes/implements.

If this is a documentation change, please briefly describe what you've changed and why.

I'm opening this as a draft because:

  • The implementation makes me sad, please suggest improvements
  • I want to figure out how to properly test the fallback and ideally verify what gets set in the cache
  • Arguably, I'm inclined to not want this code at all because the host-meta redirect goes against current best practices. But it's hard for end users to figure out why search isn't working and if/when they do manage to get another instance admin to potentially update their configuration. It's the fediverse so in this case I think it's worthwhile to try to be MAX_COMPATIBLE

This implements a fallback for discovering the webfinger endpoint in case the /.well-known/webfinger endpoint wasn't properly redirected. Some instances do this because the recommendation used to be to use host-meta for the webfinger redirect in the before times.

Closes #1558.

Checklist

Please put an x inside each checkbox to indicate that you've read and followed it: [ ] -> [x]

If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).

  • I/we have read the GoToSocial contribution guidelines.
  • I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
  • I/we have performed a self-review of added code.
  • I/we have written code that is legible and maintainable by others.
  • I/we have commented the added code, particularly in hard-to-understand areas.
  • I/we have made any necessary changes to documentation.
  • I/we have added tests that cover new code.
  • I/we have run tests and they pass locally with the changes.
  • I/we have run go fmt ./... and golangci-lint run.

@daenney daenney force-pushed the host-meta-client branch 3 times, most recently from 5c3a62a to ccf5573 Compare March 4, 2023 16:53
@daenney
Copy link
Member Author

daenney commented Mar 4, 2023

I've added a test by redirecting to a different webfinger endpoint. Not sure if/how we want to test for the cached values?

@daenney daenney force-pushed the host-meta-client branch 2 times, most recently from 7353e02 to b7214ca Compare March 4, 2023 17:01
internal/config/defaults.go Outdated Show resolved Hide resolved
internal/transport/finger.go Outdated Show resolved Hide resolved
@daenney daenney force-pushed the host-meta-client branch from b7214ca to 3bc79ec Compare March 4, 2023 17:51
internal/transport/finger.go Outdated Show resolved Hide resolved
@daenney daenney force-pushed the host-meta-client branch 2 times, most recently from 899495b to f15bd91 Compare March 4, 2023 23:06
@daenney daenney marked this pull request as ready for review March 4, 2023 23:07
@daenney daenney force-pushed the host-meta-client branch from f15bd91 to cd9e456 Compare March 5, 2023 11:31
Copy link
Contributor

@tsmethurst tsmethurst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good so far :) I'm wondering, do we need/want to cache cases where the webfinger URL didn't require any host-meta looking up, and just the initial constructed webfinger uri worked OK? I was thinking we could only cache cases where the host-meta lookup revealed a different uri from what we expected, if you see what I mean.

internal/transport/finger.go Outdated Show resolved Hide resolved
internal/transport/finger.go Outdated Show resolved Hide resolved
internal/transport/finger.go Outdated Show resolved Hide resolved
@daenney
Copy link
Member Author

daenney commented Mar 5, 2023

Looking good so far :) I'm wondering, do we need/want to cache cases where the webfinger URL didn't require any host-meta looking up, and just the initial constructed webfinger uri worked OK? I was thinking we could only cache cases where the host-meta lookup revealed a different uri from what we expected, if you see what I mean.

I've updated that now. Now only webfingerFromHostMeta can add new entry in the cache, and only if we got a cached entry + success do we renew the TTL. That should avoid us caching the default URL if that one worked. We only set the returned URL by webfingerFromHostMeta in cache after the host == url check in Finger.

@daenney daenney force-pushed the host-meta-client branch 4 times, most recently from 454e14b to 458f440 Compare March 5, 2023 12:24
internal/transport/finger.go Outdated Show resolved Hide resolved
@daenney daenney force-pushed the host-meta-client branch from 58029f4 to 5013c56 Compare March 5, 2023 17:31
suite.True(wc.Has("misconfigured-instance.com"), "expect webfinger cache to have entry for misconfigured-instance.com")
}

func (suite *FingerTestSuite) TestFingerWithHostMetaCacheStrategy() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one's a bit long but it tests that things happen as currently intended:

  • If we get a webfinger redirect, cache it
  • Future successful requests extend the TTL
  • Future failed requests don't touch the TTL so the entry will eventually expire

"github.com/superseriousbusiness/gotosocial/testrig"
)

type TransportTestSuite struct {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cribbed this from other test suites. I don't know if I need all this. But it works 😅

@daenney daenney force-pushed the host-meta-client branch from ec28755 to 4fed212 Compare March 5, 2023 20:43
testrig.StandardDBSetup(suite.db, nil)
testrig.StandardStorageSetup(suite.storage, "../../testrig/media")

ts, err := suite.federator.TransportController().NewTransportForUsername(context.TODO(), "")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idk if this should be here/how to better do this. But I need a transport.Transport to call Finger

@daenney daenney force-pushed the host-meta-client branch from 4fed212 to ed380f4 Compare March 5, 2023 20:53
daenney added 4 commits March 7, 2023 13:24
This implements a fallback for discovering the webfinger endpoint in
case the /.well-known/webfinger endpoint wasn't properly redirected.
Some instances do this because the recommendation used to be to use
host-meta for the webfinger redirect in the before times.

Closes superseriousbusiness#1558.
This adds a test suite for transport and moves the finger cache tests
into there instead of abusing the search test suite.
We don't really need a separate function for the oddly located webfinger
response as we check the full URL string anyway
@daenney daenney force-pushed the host-meta-client branch from ed380f4 to 082306d Compare March 7, 2023 12:25
@NyaaaWhatsUpDoc
Copy link
Member

Looks good! A few comments but then should be ready to go :)

@daenney daenney force-pushed the host-meta-client branch from 7874c42 to edd504d Compare March 8, 2023 12:53
@NyaaaWhatsUpDoc NyaaaWhatsUpDoc merged commit e397272 into superseriousbusiness:main Mar 8, 2023
@daenney daenney deleted the host-meta-client branch March 8, 2023 13:06
daenney added a commit to daenney/gotosocial that referenced this pull request Mar 8, 2023
When we receive an HTTP 410 on webfinger it means the resource we asked
for (the account) is gone, but the endpoint itself responded. In such
cases we want to treat the request as successful from a cache (renewal)
point of view, while still returning an error from Finger.

Follow-up for superseriousbusiness#1588
NyaaaWhatsUpDoc pushed a commit that referenced this pull request Mar 9, 2023
When we receive an HTTP 410 on webfinger it means the resource we asked
for (the account) is gone, but the endpoint itself responded. In such
cases we want to treat the request as successful from a cache (renewal)
point of view, while still returning an error from Finger.

Follow-up for #1588
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[bug] host-meta endpoint needs to be implemented and used in search
3 participants