MRF keyword_rewrite settings not visible in MRF tab in admin-fe

Support
1

Hi! I cannot see any keyword-rewrite settings anymore in the MRF section of admin-fe. I am using stable code from source.

The instance is configured to read config from the DB. It works correctly, but I can’t just see the settings where (I think) I used to find them, therefore I cannot modify them from there.
If I change them from the config/prod.secrets.exs file, they are taken into account.
In the config I have :config :pleroma, configurable_from_database: true

I attached a snapshot of the settings I can in that section.
What am I missing?

image
image1306×1036 126 KB

2

it’s strange that it shows the prefixes “Pleroma.Web.ActivityPub.MRF”. It shouldn’t show that. I’m not sure what’s wrong, but i’m guessing it’s related. Did you update admin-fe to the latest version?

3

Yes, I did. I have even rebuilt everything from scratch.

Why should Pleroma.Web.ActivityPub.MRF not be shown? Is it possible that I still had some old settings in the config file (inherited from the old pleroma instance) and that I need to clean it up?

4

bc there’s logic to not show it. But it depends on what the BE provides. The BE provides the settings which can by changed with admin-fe, and it also provides suggestions. I’m not 100% sure, but I think it doesn’t show this prefix when it finds it in the suggestions (I’m guessing this from what I saw in bugs, I haven’t went through the code).

But that’s not explaining why some settings show and others aint. Maybe try in a private window, and/or hard refresh the admin-fe (ctrl+shift+r or ctrl+F5). Or maybe check with F12 if you see calls failing in the network tab. Or errors in the console.

As for old settings; set logger to :warning and restart the instance. It should tell you if you have deprecated settings.

5

@ilja thanks for helping.

Force-refreshing the page, or loading it into firefox’s incognito or in another browser (chromium), does not change the behaviour.

From the webconsole (F12) I see no issues in the Network tab, but in the log pane there are the following errors:

Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). 2 utils.js:42:9
Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“style-src”). browser-sprite.build.js:341
Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“style-src”). browser-sprite.build.js:880
Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“style-src”). browser-symbol.js:246
6

yep agree with ilja

the prefix is weird

image
image1003×149 6.6 KB

it should look like this

how did you add this mrf config? it feels wrong

7

I think, I just recycled an old config file… But everything was working as expected till a few days ago.

Another thing that I did recently was a bit of maintenance from this page, but I cannot tell which action might have caused issues.

8

you can potentially try removing the prefixed policy name and re-adding the standard one?

9

you can potentially try removing the prefixed policy name and re-adding the standard one?

I tried. When I type anything in the Policies box no text is auto-suggested. However, I can add them, but when hitting SUBMIT I get HTTP-500.
On the server I get errors like this:

[error] Ranch listener Pleroma.Web.Endpoint.HTTP, connection process #PID<0.261719.0>, stream 1 had its request process #PID<0.261722.0> exit with reason {{%ArgumentError{message: "errors were found at the given arguments:\n\n  * 1st argument: not an atom\n"}, [{:erlang, :apply, ["SimplePolicy", :describe, []], [error_info: %{module: :erl_erts_errors}]}, {Pleroma.Web.ActivityPub.MRF, :"-describe/1-fun-0-", 2, [file: ~c"lib/pleroma/web/activity_pub/mrf.ex", line: 198]}, {Enum, :"-reduce/3-lists^foldl/2-0-", 3, [file: ~c"lib/enum.ex", line: 2510]}, {Pleroma.Web.ActivityPub.MRF, :describe, 1, [file: ~c"lib/pleroma/web/activity_pub/mrf.ex", line: 196]}, {Pleroma.Web.MastodonAPI.InstanceView, :federation, 0, [file: ~c"lib/pleroma/web/mastodon_api/views/instance_view.ex", line: 102]}, {Pleroma.Web.Nodeinfo.Nodeinfo, :get_nodeinfo, 1, [file: ~c"lib/pleroma/web/nodeinfo/nodeinfo.ex", line: 21]}, {Pleroma.Web.Nodeinfo.NodeinfoController, :nodeinfo, 2, [file: ~c"lib/pleroma/web/nodeinfo/nodeinfo_controller.ex", line: 36]}, {Pleroma.Web.Nodeinfo.NodeinfoController, :action, 2, [file: ~c"lib/pleroma/web/nodeinfo/nodeinfo_controller.ex", line: 5]}]}, {Pleroma.Web.Endpoint, :call, [%Plug.Conn{adapter: {Plug.Cowboy.Conn, :...}, assigns: %{}, body_params: %Plug.Conn.Unfetched{aspect: :body_params}, cookies: %Plug.Conn.Unfetched{aspect: :cookies}, halted: false, host: "pleroma.neuromante.net", method: "GET", owner: #PID<0.261722.0>, params: %Plug.Conn.Unfetched{aspect: :params}, path_info: ["nodeinfo", "2.0.json"], path_params: %{}, port: 80, private: %{}, query_params: %Plug.Conn.Unfetched{aspect: :query_params}, query_string: "", remote_ip: {127, 0, 0, 1}, req_cookies: %Plug.Conn.Unfetched{aspect: :cookies}, req_headers: [{"accept", "application/json, text/plain, */*"}, {"accept-encoding", "gzip, deflate, br"}, {"accept-language", "en-GB,en;q=0.9,de-DE;q=0.7,fr-FR;q=0.6,es-ES;q=0.4,it;q=0.3,ru;q=0.1"}, {"connection", "upgrade"}, {"cookie", "userLanguage=en; __Host-pleroma_key=SFMyNTY.g3QAAAACbQAAAAtvYXV0aF90b2tlbm0AAAArWjhqc2xBb0xKTFp6clJfSXR0bnNRWW5kdkhwMU9Pd2RSZUFGZXo5NURWNG0AAAAKb2F1dGhfdXNlcncDbmls.A4FZ_wArVqR1KKshYWESc8Wg9bH5h81J1J3odXK64PI; Admin-Token=Z8jslAoLJLZzrR_IttnsQYndvHp1OOwdReAFez95DV4; Auth-Host=pleroma.neuromante.net; sidebarStatus=1"}, {"dnt", "1"}, {"host", "pleroma.neuromante.net"}, {"sec-fetch-dest", "empty"}, {"sec-fetch-mode", "cors"}, {"sec-fetch-site", "same-origin"}, {"sec-gpc", "1"}, {"user-agent", "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0"}, {"x-forwarded-for", "87.154.210.204"}], request_path: "/nodeinfo/2.0.json", resp_body: nil, resp_cookies: %{}, resp_headers: [{"cache-control", "max-age=0, private, must-revalidate"}], scheme: :http, script_name: [], secret_key_base: nil, state: :unset, status: nil}, []]}} and stacktrace []

I had to add them back with the full name.

10

Hey! I fixed it :smiley: :smiley: :smiley:

I did the following:

  1. Click on the trashcan icon next to ¨Policy" in the MRF section.
    The trashcan icon disappears but the policy textbox keeps showing the policies (with their full-name).
  2. Remove everything from the text box.
  3. With a completely empty textbox, the trashcan icon appears again. I click it a second time.
  4. The webpage requests an instance reboot and shows a button to do it. I click it.
  5. The instance reboots, and I go to the Admin/MRF page again. The Policy text box is empty, but now I can type in the policy names, which are suggested as I type (in short format, without the Pleroma.Web.ActivityPub.MRF prefix).
  6. I add all policies back, and as I do that the webpage is updated showing the policy parameters.

I think, there must have been smth in the settings stored in the DB that somehow confused the logic populating the MRF page.

2 Likes
11

Thanks @ilja and @FloatingGhost for your hints. I hope this can help with finding some (minor?) interface bug and improving it.

How can I change the thread’s title to add “[SOLVED]” in front of it?

1 Like
12

Also - while recompiling, I see these errors:

00:45:23.910 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.MediaProxyWarmingPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.915 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.ForceBotUnlistedPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.915 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.NoEmptyPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.915 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.EnsureRePrepended is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.915 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.UserAllowListPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.916 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.AntiLinkSpamPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.916 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.AntiFollowbotPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.916 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.DropPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.916 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.TagPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.916 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.DirectMessageDisabledPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.916 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.NoPlaceholderTextPolicy is excluded from config descriptions, because does not implement `config_description/0` method.
00:45:23.916 [debug] Elixir.Pleroma.Web.ActivityPub.MRF.NoOpPolicy is excluded from config descriptions, because does not implement `config_description/0` method.

and this probably explains why they do not appeared in the textbox when I typed them in.
How to fix this?

It seems there is a “remotely related” bug opened on pleroma about this…

13

Nice that it works again :tada:

That output about the MRF modules is normal. That’s because they don’t implement a config_description function. That is used to show the extra policy parameters when enabled. So for those there aren’t extra policy parameters. But you should still be able to select them from the drop down.

About that pleroma issue, I’m not actually sure what it’s even about :confused: I see what seems like a conclusion, but not steps to reproduce, no actual errors (it’s all info and debug), and no explanation of why they got to that conclusion…

1 Like
14

ok here’s a potential idea that i just found literally last-second

elixir 1.15 will attempt to code-shake your application - it’ll yeet anything you don’t use

and since that frontend is generated based on loaded modules, if you were to use 1.15, it would fail to list the implementations and go “well i don’t know what these are”

by any chance were you from source?

1 Like
15

Yes @FloatingGhost I’m from source (stable) on elixir 1.15.0

16

wahay that’s what it was - 1.15 does… things

the latest release should ensure this never happens again by making sure we always load all of our custom code and don’t let the elixir compiler yeet everything

2 Likes