Status visibility checks for post interactions, stop leaking internal Activity representation (Akkoma PR 1014 and 1018)
Closes#3383
See merge request pleroma/pleroma!4400
- Adds another Pleroma.ActivityPub.Visibility.visible_for_user?/2 func
- Modifies existing tests to include a local Activity referencing a
remote Object
- Changes Announce Activity test factory to reference Objects instead of
Activities and use a different Actor for the Announce
- Changes ap_id of remote user in Announce test factory to match Objects
- Adds `object_local` option to Note factories that explicitly changes
the domain in the URL to not match the endpoint URL in the test env
to properly work with the new visibility func, since we don't store
locality of Object unlike Activities
Akkoma patches returned 403 and some of my previous commits returned 422.
This unifies the errors returned to 404 "Record not found", gaslighting
user just like we do for other endpoints and how Mastodon does it.
When a user tried to unpin a status not belonging to them, a full
MastoAPI response was sent back even if status was not visible to them.
Ditto with (un)mutting except ownership.
Before a request arrives to update_outbox, it already passed through out
Plug authentication (:authenticate), so at this point all users should
be local.
Also adds Listen Activities to the list of allowed Activities that don't
need an existing normalized object referenced in them.
A local user could previously send Announce/EmojiReact/Like activities
to their outbox referencing objects that aren't visible to them and they
would get processed as if can see them. Only requirement is knowing
the URI of the object and the users instance having C2S enabled (currently
disabled by default).
Port of commit 85171750f17725b71dcda098a5085b7f402cb061 from
Akkoma PR 1018.
Modifications from Akkoma patch:
- Pleroma.Web.ActivityPub.Utils.make_json_ld_header() calls had
activity.data as argument.
- render() had Listen activities in activity_type, Akkoma only has
Create activities there. Needs testing whether transmogrifier can
handle this.
Original commit author: Oneric <oneric@oneric.stub>
Original commit message:
Duped code just means double the chance to mess up. This would have
prevented the leak of confidential info more minimally fixed in
6a8b8a14999f3ed82fdaedf6a53f9a391280df2f and now furthermore
fixes the representation of Update activites which _need_ to have their
object inlined, as well as better interop for follow Accept and Reject
activities and all other special cases already handled in Transmogrifier.
It also means we get more thorough tests for free.
This also already adds JSON-LD context and does not add bogus Note-only
fields as happened before due to this views misuse of prepare_object
for activities. The doc of prepare_object clearly states it is only
intended for creatable objects, i.e. (for us) Notes and Questions.
