Add exhaustive e2e coverage for the Permission/Role schema fix, and real RBAC enforcement - #41
Merged
Merged
Conversation
Exercises the two UI paths that grant a role (yeti-platform/yeti#1342, yeti-platform/yeti-feeds-frontend#307): ACLEdit's per-object grants and a user's global role. rbac-group-membership.spec.ts now loops over every role ACLEdit's own UI offers (Reader/Writer/Owner) instead of just one, reopening the ACL dialog fresh each iteration since Escape (used to dismiss the identities combobox's own dropdown) isn't guaranteed to only close the topmost nested overlay. The new user-global-role.spec.ts covers UserProfile.vue's "Global role" combobox across all four values, including "No access" (0) -- the one boundary value ACLEdit's picker never offers, and the value the old Permission-flag-derived type could never express.
…orage The existing RBAC specs only ever run as admin, who bypasses every permission check, and RBAC is disabled on the integration stack -- so nothing so far actually exercises enforcement, only that ACL values get persisted correctly. Enable YETI_RBAC_ENABLED on the stack and add a test that logs a second, non-admin user's own browser session in alongside the admin's, then walks a single entity through group-based Owner access, revocation, Reader, Writer, and Owner again, asserting at each step both that the UI hides the actions that role shouldn't have (Edit/Delete/Share gating in ObjectDetails.vue/EditObject.vue) and that the backend rejects an unauthorized action attempted directly against the API, not just that the button is hidden. Parameterize helpers.ts's login() to accept a username/password, since this is the first spec that needs the browser itself logged in as a second user rather than just holding their bearer token for API calls. The initial grant targets the "All users" group rather than the second user directly, mirroring what yeti.conf's default_acls is meant to do automatically for every new object (it grants that group Owner, not merely read access, despite the config comment). That automatic grant turned out to intermittently and silently miss under load (Group.find() failing to find an existing group, permanently under-sharing the object with no retry) -- worth knowing about, but out of scope here -- so the test grants it explicitly through the same UI action instead of relying on it, for a deterministic starting point.
tomchop
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
rbac-group-membership.spec.ts: now loops over every role ACLEdit's own picker offers (Reader/Writer/Owner) instead of just one, and confirms the persisted ACL edge's exact role value via a direct API check each time.user-global-role.spec.ts(new): coversUserProfile.vue's "Global role" combobox across all four values, including "No access" (0) -- the one boundary value ACLEdit's own picker never offers.permission-enforcement.spec.ts(new): the above two specs only ever run as admin, who bypasses every permission check, and RBAC was disabled on this stack -- so nothing exercised real enforcement, only that ACL values get persisted correctly. EnablesYETI_RBAC_ENABLEDand adds a test that logs a second, non-admin user's own browser session in alongside the admin's, walking a single entity through group-based Owner access, revocation, Reader, Writer, and Owner again -- asserting both that the UI hides actions that role shouldn't have and that the backend rejects an unauthorized action attempted directly against the API.Test plan
tsc --noEmitclean on the playwright test suite