This is needed to prevent admin frontend overrides from misbehaving when
overriding AdminFE located at /pleroma/admin, since API routes are
interpreted as the first portion of their full path, ie:
/api/v1/pleroma/admin -> /api
Exercises Pleroma.ReverseProxy.Client.Hackney with follow_redirect enabled behind an HTTPS CONNECT proxy, ensuring the client follows a relative redirect and can stream the final body.
Hackney 1.25 crashes when follow_redirect is enabled behind an HTTPS CONNECT proxy and the Location header is relative (hackney_http_connect transport).
This test demonstrates the failure and verifies Tesla-level redirects work when hackney redirects are disabled.
Reproduces the Hackney 1.25 pooled redirect cleanup issue which can surface as :req_not_found when the adapter returns a Ref and the body is later fetched.
Hackney 1.25.x has redirect handling issues behind CONNECT proxies and with pools.
Disable hackney-level redirects and rely on Tesla.Middleware.FollowRedirects instead.
Also default to with_body: true so redirects can be followed reliably.
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.
