federation/in: improve reply on requests from blocked domains

Oneric commented

2025-06-08 12:38:24 +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

ci/woodpecker/pr/build-amd64 Pipeline is pending approval

Details

ci/woodpecker/pr/build-arm64 Pipeline is pending approval

Details

ci/woodpecker/pr/docs Pipeline is pending approval

Details

ci/woodpecker/pr/lint Pipeline is pending approval

Details

ci/woodpecker/pr/test/1 Pipeline is pending approval

Details

ci/woodpecker/pr/test/2 Pipeline is pending approval

Details

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

floatingghost commented

2025-06-10 17:33:12 +00:00

Owner

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

Oneric commented

2025-06-10 18:56:29 +00:00

Author

Owner

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