mirror of
https://github.com/archtechx/tenancy.git
synced 2026-02-05 13:14:05 +00:00
cleanup
This commit is contained in:
parent
a10be62587
commit
00d16d57e2
2 changed files with 86 additions and 72 deletions
|
|
@ -23,12 +23,19 @@ class CreateUserWithRLSPolicies extends Command
|
|||
protected $description = "Creates RLS policies for all tables related to the tenant table. Also creates the RLS user if it doesn't exist yet";
|
||||
|
||||
/**
|
||||
* Force RLS scoping on the tables, so that the table owner users
|
||||
* don't bypass the scoping (table owners bypass RLS by default).
|
||||
* Force, rather than just enable, the created RLS policies.
|
||||
*
|
||||
* E.g. when using a custom implementation where you create tables as the RLS user,
|
||||
* the queries won't be scoped for the RLS user unless we force the RLS scoping using
|
||||
* the `ALTER TABLE {$table} FORCE ROW LEVEL SECURITY` query in the `enableRLS` method.
|
||||
* By default, table owners bypass RLS policies. When this is enabled,
|
||||
* they also need the BYPASSRLS permission. If your setup lets you create
|
||||
* a user with BYPASSRLS, you may prefer leaving this on for additional
|
||||
* safety. Otherwise, if you can't use BYPASSRLS, you can set this to false
|
||||
* and depend on the behavior of table owners bypassing RLS automatically.
|
||||
*
|
||||
* This setting generally doesn't affect behavior at all with "default"
|
||||
* setups, however if you have a more custom setup, with additional users
|
||||
* involved (e.g. central connection user not being the same user that
|
||||
* creates tables, or the created "RLS user" creating some tables) you
|
||||
* should take care with how you configure this.
|
||||
*/
|
||||
public static bool $forceRls = true;
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue