Improve Undo handler object validation and defaults

[pfefferle]

Adds a default type of 'Announce' if not set in the activity object and refines object attribute validation to only check arrays. Updates tests to cover cases where the object is a URI, ensuring such cases pass validation.

Proposed changes:

• Adds default fallback to 'Announce' type when activity object type is missing
• Updates validation to only check object attributes when the object is an array (not a URI string)
• Adds test coverage for URI object validation scenarios

Other information:

• Have you written new tests for your changes, if applicable?

Testing instructions:

• Run an Undo for a Like or an Announce with only the ID as Object.

Changelog entry

• Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• Patch
• Minor
• Major

Type

• Added - for new features
• Changed - for changes in existing functionality
• Deprecated - for soon-to-be removed features
• Removed - for now removed features
• Fixed - for any bug fixes
• Security - in case of vulnerabilities

Message

Added a default Announce type when missing and improved validation to correctly handle URI objects.

[Copilot]

Pull Request Overview

This PR enhances the Undo handler by improving object validation to handle URI objects and adding defensive programming for missing activity types. The changes make the handler more robust when processing ActivityPub Undo activities that reference objects by URI rather than embedded objects.

• Adds default fallback to 'Announce' type when activity object type is missing
• Updates validation to only check object attributes when the object is an array (not a URI string)
• Adds test coverage for URI object validation scenarios

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
includes/handler/class-undo.php	Updates object validation and adds default type fallback logic
tests/includes/handler/class-test-undo.php	Adds test case for URI object validation

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[obenland]

If $activity['object'] is a URL, should we not resolve it and grab the underlying activity? What if it refers to a Follow activity?

[pfefferle]

atm. we don't have to. this only works for Announce and Like, so we could have that as quick win.

On the other hand, I can't check the URL any more, because it was deleted already. I contacted Brid.gy to see if we can get an example. Or if this is on purpose and they simply do not provide any queryable objects.

[obenland]

Good point, but then why not reject non-array objects if it's what we need to act on them?

[pfefferle]

Because it is an Undo of an Activity we might have to handle!?

[pfefferle]

Even if the remote object is no longer accessible, we might still have the Activity in our db. For the lookup we only need the id, so we should at least check for it.

[obenland]

Hm, not for Follows it looks like? I'm a bit confused. I would have expected a check in the Inbox to see if we find it there.

[pfefferle]

You are right... even the current code is broken! The ID is the Activity ID, not the Object ID... the problem is, that we do not store Likes and Announces in the Inbox (yet)...

[obenland]

Maybe we'd have to check both, the Inbox and the saved comments

[pfefferle]

Now I am totally confused! We store the Activity-ID in a comment meta

wordpress-activitypub/includes/collection/class-interactions.php

Line 124 in 3d3b3bb

$comment_data['comment_meta']['source_id'] = \esc_url_raw( $activity['id'] );

So the current PR works fine for Like and Announce but for Follow we need some more rework and we maybe need to store the Follow request.

[obenland]

Yeah, I don't know. Maybe it's enough to check the Inbox and be done with it. object as a string seems to be an edge case, given that we've only encountered one so far, so maybe that'll be good enough.

[pfefferle]

Close in favor of #2295