Database and application chrome is offered to an allowlisted structure user on Harper 5.3, where the list gates its DDL

Aperta
  • Qualcosa non va?
#1,894 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
authorization, frontend

Direzione di ricerca

Start with src/hooks/usePermissions.ts, src/hooks/checkOperationPermission.ts, and the permission gates for the database tree, table and schema views, dialogs, and application editor. Read how useAllowlistVersion resolves GrantBand and how allowlistGatesEveryPath applies across Harper versions. Update each surface's visibility checks to match the operations it invokes; verify that restricted actions are hidden while permitted actions remain available on both sides of the 5.3 behavior change.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

useInstanceBrowseManagePermission (src/hooks/usePermissions.ts) is true for any role with structure_user: true. The Databases tree and its context menus, the Delete Table and Delete Database modals, the table view, the schema editor and the application editor's actions all gate on it.

From Harper v5.3.0-alpha.1, verifyPerms checks the role's operations allowlist before its structure-user returns (utility/operation_authorization.ts at v5.3.0: the gate at line 773, the structure-user returns at 805 and 810). Through 5.2.x those returns come first. So on 5.3, a structure user whose allowlist leaves out drop_table, create_table, drop_database and the rest still sees those actions. Harper then refuses them with Operation '<name>' is not permitted for this role's operations configuration, in some cases after the user has confirmed a destructive dialog. I checked this against Harper's own verifyPerms on 5.2.3 (allowed), 5.3.0-beta.2 and 5.3.1 (denied).

The hook can't see the instance version. If it denied by the allowlist without the version, it would hide DDL that works on 5.2. #1885's PR leaves the hook as it is and says why in a comment.

The application-editor half of the hook (set_component_file, drop_component, deploy_component, set_env_value, restart_service) has a related, older gap. Those operations aren't structure-user operations, so a structure user can run them only if its allowlist lists them, and that holds on every version. A structure user with no allowlist, or a list that leaves them out, sees that chrome and gets a 403.

Harper is still the authority, so this is a UI mismatch, not a privilege escalation.

Suggested fix

Split the one boolean into checks for each surface: drop_table for Delete Table, drop_database for Delete Database, create_table/create_attribute for the schema editor, and the application-editor operations for that half. Resolve the instance's GrantBand (useAllowlistVersion) so a structure user's DDL is checked against the list only where allowlistGatesEveryPath(band) holds. checkAnyOperationAllowed in src/hooks/checkOperationPermission.ts already matches the gate's expansion.

🤖 Generated by Claude Code (Claude Opus); posted via @dawsontoth.

Lingua principale
TypeScript
Stelle
5
Fork
4
Merge medio
1g 20h
PR unite (30g)
140

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/studio

Tutte le issue di HarperFast/studio

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.