Conversation

Notices

1. Embed this notice
   Max Thompson Jr. (famine@fedi.ruinouspowe.rs)'s status on Saturday, 05-Nov-2022 00:26:44 JST Max Thompson Jr.

   • Alex Gleason

   Hey @alex

   I was poking around(and comparing) some rebased/pleroma code, and I’m curious how you handled conferring admin:read:reports and admin:read:accounts

   it looks like the behavior is outlined in

   /api_spec/operations/admin/report_operation.ex but it appears identical for rebased and pleroma

   so obvs I don’t get how this is actually implemented. Can you explain that to me in broad strokes?

   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Saturday, 05-Nov-2022 00:26:43 JST Alex Gleason

     in reply to
     Not sure what you mean by conferring, but we just request the `admin` scope in Soapbox and it automatically gives us permission to everything beneath.
   • Embed this notice
     Max Thompson Jr. (famine@fedi.ruinouspowe.rs)'s status on Saturday, 05-Nov-2022 00:33:42 JST Max Thompson Jr.

     in reply to

     • Alex Gleason

     let me give you more context-

     I was dorking around with adding soapbox to a modified pleroma backend, and I was getting 403 errors for admin users as it was trying to GET config, reports?state=open, and the users list that needs approval.

     The FE was returning errors around:

     admin:read:accounts admin:read:reports

     I decided to poke around the pleroma code and rebased code to try and figure out where this was determined, but the file I mentioned was practically identical for both so I was curious what the actual mechanism was to provide this to the FE when it’s requested

   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Saturday, 05-Nov-2022 00:33:42 JST Alex Gleason

     in reply to
     Did you modify it by changing its name in mix.exs? That could mess up feature detection and cause Soapbox to not request admin permissions on the token.