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

Abierto
  • ¿Algo no está bien?
#1,894 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
authorization, frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
5
Forks
4
Merge medio
1 d 12 h
PR fusionados (30 d)
65

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de HarperFast/studio

Todos los issues de HarperFast/studio

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.