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.
Creating Actors via C2S doesn't make sense, thus it should fail.
Tests creating Actors with type: Application/Person/Service.
All Create Activities for new Actors currently fail with
`validator not set` in the pipeline.
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.
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 272799da6242dbf7387d2d42dfc98512cd7efd7e from
Akkoma PR 1018.
Changes from Akkoma commit:
- changed order of arguments in CommonAPI.(un)block, because Akkoma
hasn't backported our change for the unified arg order yet
In particular this covers the case
e88f36f72b5317debafcc4209b91eb35ad8f0691 was meant to fix and
Port of Akkoma PR 1014 with a few changes:
- comments regarding akkomafe changed to Pleroma-FE when applicable
- different error message for replying to/interacting with invisible post
in Pleroma.Web.CommonAPI.ActivityDraft.in_reply_to/1
- split "doesn't do funny things to other users favs" test into three:
- can't unfavourite post that isn't favourited
- can't unfavourite other user's favs
- can't unfavourite other user's favs using their activity
- switched order of args for some CommonAPI function since Akkoma hasn't
backported our old change for that
Pleroma.Web.CommonAPI.ActivityDraft.in_reply_to/1 now refactored to use
`with` statement as in Akkoma. Some defp in_reply_to/1 were therefore removed
Original PR author: Oneric
Original commit message:
It doesn't make sense to like, react, reply, etc to something you cannot
see and is unexpected for the author of the interacted with post and
might make them believe the reacting user actually _can_ see the post.
Wrt to fav, reblog, reaction indexes the missing visibility check was
also leaking some (presumably/hopefully) low-severity data.
Add full-API test for all modes of interactions with private posts.
Hackney interferes with out URI encoding and implements older RFC 2396
instead of RFC 3986 which we and Elixir implement. As an example "'"
and "!" will get encoded by it and cause problems with our MediaProxy
making unexpected 302 redirects.
If an admin supplies a different function via *.secret.exs, we
don't override it.
https://github.com/benoitc/hackney/issues/399
This solves the issue with Guardian rich media cards not loading, thanks
to them using "," and ":" in queries which get improperly encoded.
Guardian also needs specific ordering of the query keys, this also fixes
that.
