Hi @Max
It’s not a WeWeb thing, it’s a Supabase thing. The correct solution is for supabase to allow managing settings on the generated key to restrict what you can do with it. It’s a really common pattern. For example when you create a private key on Airtable (or Xano) you can select exactly which access you grant to the key, per workspace, per project, per operation.
We will explore if there is a way to make the service role optional while retaining the core features.
Without admin access we may not be able to parse your database and provide you the list of tables and columns anymore for example, it would probably defeat the purpose of having a plugin for many people. It would also require you to be connected as a user first to edit your project and RLS will impact your experience while editing. So for your collaborators to be able to work with your project you will need to give them admin access through RLS and so it will defeat the purpose to make the service role token optional in a way.
Still, I 100% understand your concern, nocode platforms have to step up their game and move away from the pattern of giving full access to each other to communicate, by offering a way to manage the connection between them with more granularity.
On our side the only thing we can do is to require only the minimum amount of access we need, but it depends very much on the external service we’re connecting to.
Note =>
I’m guessing that WeWeb uses the key to check the user’s role on page changes. That means it is probably not encrypted on the server either.
No. The service role key is only used in the editor, not in production, not even server side. The service role key is used to generate a front end sdk admin client with admin privilege, so you can manage your users from the Editor (Auth plugin) and we can display the table and columns on the CRUD actions.