Repository navigation
Find remote actors after an update - #4048
Merged
Merged
Conversation
1 of 2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Proposed changes:
guidin two spellings. On insert,&becomes&. On everywp_update_post(), core ignores theguidit is given, reads the stored one in thedisplaycontext and writes theesc_url()form back (&, and'as').Remote_Actors::get_by_uri(),get_existing_uris()andFollowers::get_by_uri()only looked for the insert form. So an actor with&or'in its id was not found after its first refresh, and the next activity created a second actor post, without its followers and blocks.get_stored_id_forms(). Every lookup of a stored id uses it: theguidqueries inRemote_Actors,Followers,Inbox,Remote_PostsandOutbox, and the Follow lookups inFollowing.guidas if it were the actor's id. For an id with&or'that sent or compared the escaped string. These places now undo that escaping withunescape_guid()before they use the id:Following), so the remote server recognizes itself as the object;Remote_Posts);Sanitize, the WebFinger lookup, and the REST followers and following lists;activitypub_add_user_blockandactivitypub_remove_user_blockhooks.Moderation), so a block still applies after the blocked actor was updated;Interactions);Locationheader and the Stream log.unescape_guid()reverses only the escapes core adds to aguid. The inboxUndodid the same inline before and uses it now too.guidin the insert form, so the lookup finds a moved actor.InboxandRemote_Postssaid theesc_url()form comes from older releases. Every update writes it, so I fixed them and added the details to AGENTS.md, so we don't have to work this out again.For ids with
&or', REST clients and hook consumers now get the real id instead of the escaped one. Follow activities sent before this change carry the escaped id, soFollowinglooks for all three spellings.Not covered:
?a=1&b=2after an update and a literal?a=1&b=2). No server writes such ids, so no lookup checks for it. The exact fix would be a lookup by the id hash inpost_namefor all collections at once, which needs a backfill first because older rows don't have it.guidto the cleanup hooks, which expect a post id. That is a separate bug.Other information:
Testing instructions:
vendor/bin/phpunit --filter "Test_Remote_Actors|Test_Followers|Test_Following|Test_Remote_Posts|Test_Moderation|test_get_stored_id_forms|test_unescape_guid".test_lookup_after_update_with_special_charactersandtest_get_by_uri_after_update_with_special_characterscreate an actor, update it and look it up again, for every id in the shared URI cases. On trunk they fail for the ids with&or'.test_follow_sends_unescaped_actor_idandtest_follow_finds_follow_sent_with_escaped_idcheck the Follow of an actor with&in its id, and that a Follow sent with the escaped id is still found.test_update_accepts_owner_with_escaped_idchecks the owner check for updates of cached posts, andtest_block_applies_after_actor_updatethat a block still applies after the blocked actor was updated. Each fails with its fix reverted.Changelog entry
Entry lives in
.github/changelog/fix-remote-actor-lookup-after-update.