Access Control: the Subject picker on the Administrators tab finds no user on an instance with three users, while the grant by email works

Abierto
  • ¿Algo no está bien?
#7,908 1 comentario 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
47/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp, postgresql
Área
authentication, authorization

Línea de trabajo

Start with AccessControlLayoutArea in src/MeshWeaver.Graph and the canonical queries in src/MeshWeaver.Mesh.Contract/Security/AccessSubjectQueries; compare the users query and picker results with the successful email grant path. Check the Postgres planner and auth lookup mirror behavior described in #3206, then reproduce whether the users query returns no rows or fails. Done when the picker lists provisioned users on the Administrators tab and the relevant behavior is covered by a test.

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

Descripción

area:security bug sev:L

Why this repository, and prior art

The Subject picker of the Access Control form is AccessControlLayoutArea (src/MeshWeaver.Graph) with the canonical queries of AccessSubjectQueries (src/MeshWeaver.Mesh.Contract/Security), both in this repository; the Administrators tab of the instance app renders that form for the Admin node. Prior art checked: #213 and #217 (the picker could not select a user; canonical queries and in-memory filtering, 2026-07/08), #338 (grant by email), #3202 and #3206 (unanchored queries refused by the Postgres planner; nodeType:User namespace:"" is the users query). None describes a picker that returns no user at all while the grant by email succeeds.

What happened

On a customer estate's working instance (enterprise plan, build 3.1.12572, commit 3f32f7c1, PostgreSQL storage, Orleans clustering, two replicas; invitation-only, Microsoft sign-in only), the platform administrator opened the Administrators tab (/Admin/Settings/GlobalAdmin) on 2026-11-05 between 15:30 and 15:45 CET to appoint a second administrator.

  1. The picker "Add user or group" answered "no items found", both for the person onboarded minutes earlier and for a person onboarded the day before (2026-11-04), whose invitation shows Accepted. The administrator's own account was not tested.
  2. The email field of the same Add row worked at once: typing the new person's address gave "… already has an account — granted Admin here." The Administrators tab then listed both administrators, and the Admin app opened for the new one.
  3. /health of the same replica at 15:34 CET: user_directory: Healthy — user directory hydrated: 3 user(s) indexed by email.

What I did not establish

  1. Whether the users query (nodeType:User namespace:"", routed to the auth lookup mirror) returned zero rows, was refused as insufficiently anchored on the Postgres planner (#3206's rule), or failed before the picker loaded its set; the instance log was not read.
  2. Whether the page had been opened before the newer account existed (the picker loads its subject set once); the older account rules that out as the only cause.
  3. Whether the same picker finds users on other pages of the same instance (a Space's Access Control), and whether the groups half of the query answered.

Expected

The picker lists every provisioned user, as #217 established; the email route is the fallback for not-yet-provisioned people (#338), not for existing accounts.

Severity

sev:L, proposed: the administrator grant could be given through the email route, so nothing was blocked; the picker's answer is misleading on an instance that is being handed over.

Lenguaje dominante
C#
Estrellas
12
Forks
5
Merge medio
5 h 11 min
PR fusionados (30 d)
978

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

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 Systemorph/MeshWeaver

Todos los issues de Systemorph/MeshWeaver

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.