cbce4555ff
TeamManager could not manage the roster: updateRule allowed self-update
only and deleteRule was superuser-only. The same self-update rule also
left a privilege escalation open — it did not restrict fields, so any
authenticated user could PATCH their own role to "admin".
- team_members rules (migration 1781000003 + base migration + setup
script mirror):
update: (@request.auth.id = id && @request.body.role:isset = false)
|| @request.auth.role = "admin"
delete: @request.auth.role = "admin"
Self-service onboarding keeps working (it never touches role); the
role field is admin-only; deletion is admin-only.
- pb_hooks/team_members.pb.js: the ENTRA_ADMIN_EMAILS resync is now
escalate-only — it guarantees admin for allow-list members on every
login but no longer demotes, otherwise every TeamManager promotion
would revert on the member's next sign-in (ADR-004 amended).
- TeamManager.jsx: info text updated to the new behaviour.
Verified with a two-identity mock-OIDC matrix (11/11): allow-list vs
regular login, self-escalation blocked while onboarding self-update
still works, cross-user update/delete blocked, admin promote/demote/
delete work, promotion survives the member's next login, allow-list
admin stays admin. Regression: #22 matrix 9/9, #24 matrix 8/8, #18
harness 15/15, npm test 112/112, eslint clean.
Closes #27
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
53 lines
1.8 KiB
JavaScript
53 lines
1.8 KiB
JavaScript
/// <reference path="../pb_data/types.d.ts" />
|
|
//
|
|
// Issue #27 — TeamManager roster management + close role self-escalation.
|
|
//
|
|
// The collection shipped with `updateRule: '@request.auth.id = id'` and
|
|
// `deleteRule: null`. That broke the TeamManager admin panel (admins could
|
|
// not change roles or remove members) AND left a privilege escalation open:
|
|
// the self-update rule did not restrict fields, so any authenticated user
|
|
// could PATCH their own `role` to "admin".
|
|
//
|
|
// New rules:
|
|
// update — a user may update their own record but NOT the `role` field
|
|
// (onboarding only touches enrollment fields); admins may update
|
|
// anyone, including `role`.
|
|
// delete — admins only.
|
|
//
|
|
// Environments that have not applied 1781000000 yet get these rules directly
|
|
// from that (updated) migration; this follow-up exists for databases where it
|
|
// already ran (Labs). Applying both is harmless (same values).
|
|
const UPDATE_RULE = '(@request.auth.id = id && @request.body.role:isset = false) || @request.auth.role = "admin"';
|
|
const DELETE_RULE = '@request.auth.role = "admin"';
|
|
|
|
migrate((app) => {
|
|
let col;
|
|
try {
|
|
col = app.findCollectionByNameOrId("team_members");
|
|
} catch (_) {
|
|
console.log("team_members_admin_rules: team_members does not exist — skipping.");
|
|
return;
|
|
}
|
|
if (col.type !== "auth") {
|
|
console.log("team_members_admin_rules: team_members is not an auth collection — skipping.");
|
|
return;
|
|
}
|
|
col.updateRule = UPDATE_RULE;
|
|
col.deleteRule = DELETE_RULE;
|
|
app.save(col);
|
|
}, (app) => {
|
|
// Down: restore the previous (self-update only, superuser delete) rules.
|
|
let col;
|
|
try {
|
|
col = app.findCollectionByNameOrId("team_members");
|
|
} catch (_) {
|
|
return;
|
|
}
|
|
if (col.type !== "auth") {
|
|
return;
|
|
}
|
|
col.updateRule = '@request.auth.id = id';
|
|
col.deleteRule = null;
|
|
app.save(col);
|
|
});
|