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

Aperta
  • Qualcosa non va?
#7,908 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

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

Direzione di ricerca

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.

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

Descrizione

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.

Lingua principale
C#
Stelle
12
Fork
5
Merge medio
5h 10m
PR unite (30g)
979

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

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

Tutte le issue di Systemorph/MeshWeaver

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.