Conversation

Notices

1. cassidyclown (cassidyclown@clubcyberia.co)'s status on Wednesday, 31-May-2023 15:53:03 JST cassidyclown
   attention cyberians: media proxy has been turned back on
   •  (mint@ryona.agency)'s status on Wednesday, 31-May-2023 15:53:02 JST 

     in reply to
     @cassidyclown Media from baest is broken since instead of inserting the media directly with correct address, it uses the default /media/ and puts a redirect which Hackney can't follow when using proxy. The bug has been open for six years.
     https://github.com/benoitc/hackney/issues/273
     In the meantime you could probably whitelist it from proxying.
   • pomstan (pomstan@xn--p1abe3d.xn--80asehdb)'s status on Wednesday, 31-May-2023 17:21:34 JST pomstan

     in reply to

     • 

     @mint @cassidyclown what about flattening the redirect directly on your proxy?

      likes this.
   •  (mint@ryona.agency)'s status on Wednesday, 31-May-2023 17:25:36 JST 

     in reply to

     • pomstan
     @pomstan @cassidyclown That might require some more advanced proxy that can MitM HTTPS traffic. I skimmed through Privoxy docs and haven't found anything that could do that.
     Machismo likes this.
   • pomstan (pomstan@xn--p1abe3d.xn--80asehdb)'s status on Wednesday, 31-May-2023 17:28:20 JST pomstan

     in reply to

     • 

     @mint @cassidyclown ah, so its a transport-layer proxy, ok

      likes this.
   • :blank: (i@declin.eu)'s status on Wednesday, 31-May-2023 18:01:30 JST :blank:

     in reply to

     • pomstan
     • 
     @mint @cassidyclown @pomstan you could probably have it follow the redirect by just following up on the 301 yourself at as they do in https://github.com/edgurgel/httpoison/issues/112
     
     based on
     https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/reverse_proxy/client/wrapper.ex#L11
     and
     https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/reverse_proxy.ex#L159
     
     @redirect_statuses [301, 302, 303, 307, 308]
     defp get_location(headers) do
     {_h, location} =
     Enum.find(headers, fn {header, _location} ->
     String.downcase(header) == "location"
     end)
     
     location
     end
     
     @impl true
     def request(method, url, headers, body \\ "", opts \\ []) do
     res = client().request(method, url, headers, body, opts)
     
     case res do
     {:ok, code, headers, _client} when code in @redirect_statuses ->
     client().request(method, get_location(headers), headers, body, opts)
     
     {:ok, code, headers} when code in @redirect_statuses ->
     client().request(method, get_location(headers), headers, body, opts)
     
     _ ->
     res
     end
     end
      likes this.
   •  (mint@ryona.agency)'s status on Thursday, 01-Jun-2023 00:03:53 JST 

     in reply to

     • pomstan
     • :blank:
     @i @cassidyclown @pomstan Apparently, there is already a middleware for following redirects in Tesla.
     https://github.com/elixir-tesla/tesla/blob/master/lib/tesla/middleware/follow_redirects.ex
     It's enabled by default for Gun (which has its own problems when paired with Tesla: https://github.com/elixir-tesla/tesla/issues/552, zero comments as usual) and for dev environments.
     https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/http.ex#L105
     Enabling that middleware for Hackney might've fully solved the problem with redirects as well, but for whatever reason ReverseProxy does not use Pleroma's default HTTP wrapper, instead having its own. Regardless, this would solve the issue with redirects on federation-related requests. It's not as apparent, but I couldn't just forcefetch /notice/ links with the proxy on, plus there's been at least one instance that serves actors' AP IDs on its main domain but redirects requests to them to subdomain, essentially breaking all federation.
   •  (mint@ryona.agency)'s status on Thursday, 01-Jun-2023 01:20:09 JST 

     in reply to

     • pomstan
     • :blank:
     @i @cassidyclown @pomstan Your code does work, but the request in `case res` was seemingly sending the response headers as HTTP headers for second request, so one has change the variable name to something else. I'll add some checks in case something defines follow_redirect already and then push a proper patch.
   • :blank: (i@declin.eu)'s status on Thursday, 01-Jun-2023 01:30:47 JST :blank:

     in reply to

     • pomstan
     • 
     @mint @cassidyclown @pomstan :arg-r::arg-i::arg-g::arg-h::arg-t: :arg-o::arg-n:
      likes this.
   •  (mint@ryona.agency)'s status on Thursday, 01-Jun-2023 02:22:48 JST 

     in reply to

     • pomstan
     • 
     • :blank:
     @i @cassidyclown @pomstan Alright, it's up.
     Mediaproxy: https://gitgud.io/ryonagency/pleroma/-/commit/ed31bad2c481633520cc593912586b403c1ac6d4
     Everything else, inc. federation (should've made it one commit, but was in a hurry):
     https://gitgud.io/ryonagency/pleroma/-/commit/08c8abc053d2b1b36f4cc21402a8df254a6c7795
     https://gitgud.io/ryonagency/pleroma/-/commit/8e8b3be31345ce18150b38ebbe84a3fc23f13e0e
     All redirects should now be handled by either Pleroma (in case of mediaproxy) or Tesla (everything else); disabling redirect handling for either of them ([:http, :adapter, :follow_redirect] or [:media_proxy, :proxy_opts, :http, :follow_redirect]) should fail fetching gracefully with 301/302/etc in reply.
   •  (mint@ryona.agency)'s status on Thursday, 01-Jun-2023 02:27:42 JST 

     in reply to

     • pomstan
     • 
     • :blank:
     @cassidyclown @i @pomstan Still not enabling mediaproxy myself, btw. But at least I can now sleep easier knowing that the bug is circumvented at least locally.
   • :blank: (i@declin.eu)'s status on Thursday, 01-Jun-2023 02:37:38 JST :blank:

     in reply to

     • pomstan
     • 
     @mint @cassidyclown @pomstan media proxy is just a waste anyways with all the porn bots, glad the suggestion worked out, even if it wasn't real code
      likes this.