[backend] fix(multi-tenancy): dev env with openaev_owner new user (#0000)#5694
[backend] fix(multi-tenancy): dev env with openaev_owner new user (#0000)#5694corinnekrych merged 16 commits intorelease/currentfrom
Conversation
github-actions
Bot
added
the
filigran team
corinnekrych
changed the title
| * openaev_app} that the application adopts at runtime via {@code SET ROLE openaev_app} (configured | ||
| * in {@code spring.datasource.hikari.connection-init-sql}). Flyway continues to run as the | ||
| * superuser for DDL operations. | ||
| * <p>Prerequisites (run by DBA once): |
There was a problem hiding this comment.
Question : Does that mean that we need to provide a clear documentation to the existing users that they need to run this before upgrading ?
There was a problem hiding this comment.
Yes, this is a pre-requisites
…nt out SET ROLE openaev_app
| * | ||
| * <pre> | ||
| * CREATE ROLE openaev_app NOLOGIN NOSUPERUSER; | ||
| * GRANT openaev_app TO openaev_owner; |
There was a problem hiding this comment.
I don't think openaev_owner will be created on most setups by the time this runs
There was a problem hiding this comment.
what do you mean?
the user is created via the container bootstrap/seed init-db.sql
it works in dev env, tested locally
what i dont know how to fix - I'm stuck on that one - is how to make drone working as it is not using container to run api-test
| CREATE USER openaev_owner WITH PASSWORD 'openaev' NOSUPERUSER CREATEROLE; | ||
|
|
||
| -- 3. Grant the app role to the owner (so SET ROLE works at runtime) | ||
| GRANT openaev_app TO openaev_owner; |
There was a problem hiding this comment.
Can you explain why this grant is necessary?
There was a problem hiding this comment.
This grant is necessary to make SET ROLE openaev_app work at runtime.
In PostgreSQL, SET ROLE only works if the current session user is a member of the target role. Without GRANT openaev_app TO openaev_owner, any attempt by the app to do SET ROLE openaev_app would fail with a "permission denied" error.
By granting openaev_app to openaev_owner, the application can switch into the openaev_app role at runtime, which ensures RLS policies are evaluated under the correct role context — enforcing tenant isolation as intended.
openaev_owner owns the tables (required to run DDL/RLS policies), but table ownership bypasses RLS at query time. The application therefore adopts openaev_app via SET ROLE — a non-owner role that RLS policies are enforced on. GRANT openaev_app TO openaev_owner makes that role switch possible.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## release/current #5694 +/- ##
=====================================================
- Coverage 40.40% 40.39% -0.01%
Complexity 6112 6112
=====================================================
Files 2123 2123
Lines 56997 56989 -8
Branches 7230 7229 -1
=====================================================
- Hits 23028 23023 -5
+ Misses 32613 32611 -2
+ Partials 1356 1355 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
3 participants
Proposed changes
Flyway migration to use
openaev_ownerfor running migrationTo test it, in your
application-dev.propertieschange:Testing Instructions
Related issues
Checklist
Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...