federation/in: improve reply on requests from blocked domains #940

Merged
Oneric merged 1 commit from Oneric/akkoma:httpsig-mrf-reply into develop 2025-06-10 19:17:20 +00:00
Owner

Previously all such requests led to '401 Unauthorized'
which might have triggered retries.
Now, depending on whether MRF info can be disclosed, either an
informative '403 Forbidden' response is sent, or a success or
non-existence of the requested object is faked.

Notably this change also now causes all signed fetch requests from
blocked domains to be rejected even if authorized_fetch isn’t enabled.

Fixes: #929


Imho rejecting requests from blocked domains makes sense regardless of auth_fetch, but then again I always enable auth_fetch anyway.
If instead signed GET requests from blocked domains should still continue to succeed, the following can be used (and the added tests need to be adapted):

  defp maybe_halt(conn, {:reject, _}) do
    transparency = Pleroma.Config.get!([:mrf, :transparency])
    authfetch = Pleroma.Config.get!([:activitypub, :authorized_fetch_mode])

    cond do
      (conn.method == "POST" or authfetch) and transparency ->
        conn
        |> resp(403, "Forbidden")
        |> halt()

      conn.method == "POST" ->
        conn
        |> resp(202, "Accepted")
        |> halt()

      # If authorized_fetch isn’t enabled, even blocked domain ought to still be able to fetch stuff
      authfetch ->
        conn
        |> resp(404, "Not found")
        |> halt()

      true ->
        conn
    end
  end
Previously all such requests led to '401 Unauthorized' which might have triggered retries. Now, depending on whether MRF info can be disclosed, either an informative '403 Forbidden' response is sent, or a success or non-existence of the requested object is faked. Notably this change also now causes all signed fetch requests from blocked domains to be rejected even if authorized_fetch isn’t enabled. Fixes: https://akkoma.dev/AkkomaGang/akkoma/issues/929 -------- Imho rejecting requests from blocked domains makes sense regardless of auth_fetch, but then again I always enable auth_fetch anyway. If instead signed GET requests from blocked domains should still continue to succeed, the following can be used *(and the added tests need to be adapted)*: ```elixir defp maybe_halt(conn, {:reject, _}) do transparency = Pleroma.Config.get!([:mrf, :transparency]) authfetch = Pleroma.Config.get!([:activitypub, :authorized_fetch_mode]) cond do (conn.method == "POST" or authfetch) and transparency -> conn |> resp(403, "Forbidden") |> halt() conn.method == "POST" -> conn |> resp(202, "Accepted") |> halt() # If authorized_fetch isn’t enabled, even blocked domain ought to still be able to fetch stuff authfetch -> conn |> resp(404, "Not found") |> halt() true -> conn end end ```
Oneric added 1 commit 2025-06-08 12:38:25 +00:00
federation/in: improve reply on requests from blocked domains
Some checks are pending
ci/woodpecker/pr/build-amd64 Pipeline is pending approval
ci/woodpecker/pr/build-arm64 Pipeline is pending approval
ci/woodpecker/pr/docs Pipeline is pending approval
ci/woodpecker/pr/lint Pipeline is pending approval
ci/woodpecker/pr/test/1 Pipeline is pending approval
ci/woodpecker/pr/test/2 Pipeline is pending approval
57c129d83f
Previously all such requests led to '401 Unauthorized'
whih might have triggered retries.
Now depending on whether MRF info can be disclosed, either an
informative '403 Forbidden' response is sent, or a success or
non-existence of the requested object is faked.

Notably this change also now causes all signed fetch requests from
blocked domains to be rejected even if authorized_fetch isn’t enabled.

Fixes: #929
Oneric force-pushed httpsig-mrf-reply from 57c129d83f to 20abc658d7 2025-06-08 12:54:37 +00:00 Compare

404 is indeed the correct way to hide an unauth, i agree with this decision

though should we actually care about transparency? i see why you've done it, but it might make sense to just apply the 202 or 404 model everywhere, and give out as little information over AP as we can get away with

404 is indeed the correct way to hide an unauth, i agree with this decision though should we actually care about `transparency`? i see why you've done it, but it might make sense to just apply the 202 or 404 model everywhere, and give out as little information over AP as we can get away with
Oneric force-pushed httpsig-mrf-reply from 20abc658d7 to 0a9e7d4712 2025-06-10 18:53:40 +00:00 Compare
Author
Owner

sure, i don’t mind always using 202/404. Updated the commit to do just that

sure, i don’t mind always using 202/404. Updated the commit to do just that
floatingghost approved these changes 2025-06-10 19:11:06 +00:00
Oneric merged commit 7f6ebcb12e into develop 2025-06-10 19:17:20 +00:00
Oneric deleted branch httpsig-mrf-reply 2025-06-10 19:17:20 +00:00
Sign in to join this conversation.
No description provided.