[bugfix] Fix potential dereference of accounts on own instance #757
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR updates some of the logic in
GetRemoteAccount
to ensure that accounts from our own instance are never webfingered. This has happened before and causes an issue where the domain of the account is set toAccountDomain
orHost
, which means that the account in question is no longer picked up correctly byGetLocalAccountByUsername
, which causes all sorts of knock-on issues.Rather than trying to track down + add checks for every instance where callers might be passing a local account into this function, it's easier to just add the logic into
GetRemoteAccount
instead.Callers should still try to avoid passing local accounts into
GetRemoteAccount
because it's confusing, but at least if they do it now it won't break the account that was passed in.To support this update, this PR also adds another index to the account cache, for
username
anddomain
lookups, which replaces thedb.Where
that was being used before. So, should be a little faster in some places too!