Portal-BFF:/api/worklist nimmt zusätzlich X-Workflow-Token (Zielmodul workflow, PORTAL_WORKFLOW_TOKEN_AUDIENCE, Standard workflow). Das Token wird mit Core-JWKS geprüft und muss denselben Benutzer und Mandanten wie das Portal-Token haben, sonst 401. Der Aufruf an die Workflow-API geht dann per Authorization: Bearer, ohne X-User-Id. Ohne das Token bleibt der Übergangsweg.
workflow-approvals, workflow-tasks: Mit NEXT_PUBLIC_CORE_API_BASE laufen die Aufrufe über createSession (module: workflow) mit Bearer. Die BFF-Routen reichen Authorization weiter und ignorieren userId/tenant aus der URL. Die Identität kommt aus der Sitzung statt aus ?user=. Ohne die Variable bleibt das alte Verhalten.
Tests: Portal 72/72, workflow-approvals 9/9, workflow-tasks 11/11, kein neuer tsc-Fehler, next build für workflow-tasks ok.
Voraussetzungen
Core: workflow in NEXARCH_ACCOUNT_MODULE_AUDIENCES, account-api läuft.
Workflow-App: NEXARCH_WORKFLOW_APP_JWKS_URL gesetzt. NEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTH bleibt, bis auch workflow-cases und routing-rules umgestellt sind (Schritt 3).
## Änderung (Arbeitskarte D-05, Schritte 1 und 2)
- **Portal-BFF:** `/api/worklist` nimmt zusätzlich `X-Workflow-Token` (Zielmodul `workflow`, `PORTAL_WORKFLOW_TOKEN_AUDIENCE`, Standard `workflow`). Das Token wird mit Core-JWKS geprüft und muss denselben Benutzer und Mandanten wie das Portal-Token haben, sonst 401. Der Aufruf an die Workflow-API geht dann per `Authorization: Bearer`, ohne `X-User-Id`. Ohne das Token bleibt der Übergangsweg.
- **workflow-approvals, workflow-tasks:** Mit `NEXT_PUBLIC_CORE_API_BASE` laufen die Aufrufe über `createSession` (`module: workflow`) mit Bearer. Die BFF-Routen reichen `Authorization` weiter und ignorieren `userId`/`tenant` aus der URL. Die Identität kommt aus der Sitzung statt aus `?user=`. Ohne die Variable bleibt das alte Verhalten.
- Tests: Portal 72/72, workflow-approvals 9/9, workflow-tasks 11/11, kein neuer tsc-Fehler, `next build` für workflow-tasks ok.
## Voraussetzungen
- Core: `workflow` in `NEXARCH_ACCOUNT_MODULE_AUDIENCES`, `account-api` läuft.
- Workflow-App: `NEXARCH_WORKFLOW_APP_JWKS_URL` gesetzt. `NEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTH` bleibt, bis auch `workflow-cases` und `routing-rules` umgestellt sind (Schritt 3).
- Nicht gegen einen echten Core getestet.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
patrick
added 2 commits 2026-10-28 15:02:18 +01:00
Mit NEXT_PUBLIC_CORE_API_BASE holen die Frontends ein workflow-Token ueber die
Sitzung und senden Authorization; die BFF-Routen reichen es weiter und ignorieren
userId/tenant aus der URL. Ohne die Variable bleibt der Uebergangsweg.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Schritt 3 ergänzt: workflow-cases und routing-rules wie workflow-approvals und workflow-tasks auf Sitzung und Bearer umgestellt (8 BFF-Routen, Libs, Seiten, je ein Bearer-Test). Tests auf 131: workflow-cases 9/9, routing-rules 11/11, kein neuer tsc-Fehler. Der Übergangsschalter NEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTH kann erst entfallen, wenn alle Frontends mit NEXT_PUBLIC_CORE_API_BASE gebaut sind.
Schritt 3 ergänzt: `workflow-cases` und `routing-rules` wie `workflow-approvals` und `workflow-tasks` auf Sitzung und Bearer umgestellt (8 BFF-Routen, Libs, Seiten, je ein Bearer-Test). Tests auf 131: workflow-cases 9/9, routing-rules 11/11, kein neuer tsc-Fehler. Der Übergangsschalter `NEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTH` kann erst entfallen, wenn alle Frontends mit `NEXT_PUBLIC_CORE_API_BASE` gebaut sind.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
patrick
merged commit 21838e87d0 into main2026-10-28 15:05:39 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Änderung (Arbeitskarte D-05, Schritte 1 und 2)
/api/worklistnimmt zusätzlichX-Workflow-Token(Zielmodulworkflow,PORTAL_WORKFLOW_TOKEN_AUDIENCE, Standardworkflow). Das Token wird mit Core-JWKS geprüft und muss denselben Benutzer und Mandanten wie das Portal-Token haben, sonst 401. Der Aufruf an die Workflow-API geht dann perAuthorization: Bearer, ohneX-User-Id. Ohne das Token bleibt der Übergangsweg.NEXT_PUBLIC_CORE_API_BASElaufen die Aufrufe übercreateSession(module: workflow) mit Bearer. Die BFF-Routen reichenAuthorizationweiter und ignorierenuserId/tenantaus der URL. Die Identität kommt aus der Sitzung statt aus?user=. Ohne die Variable bleibt das alte Verhalten.next buildfür workflow-tasks ok.Voraussetzungen
workflowinNEXARCH_ACCOUNT_MODULE_AUDIENCES,account-apiläuft.NEXARCH_WORKFLOW_APP_JWKS_URLgesetzt.NEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTHbleibt, bis auchworkflow-casesundrouting-rulesumgestellt sind (Schritt 3).🤖 Generated with Claude Code
Schritt 3 ergänzt:
workflow-casesundrouting-ruleswieworkflow-approvalsundworkflow-tasksauf Sitzung und Bearer umgestellt (8 BFF-Routen, Libs, Seiten, je ein Bearer-Test). Tests auf 131: workflow-cases 9/9, routing-rules 11/11, kein neuer tsc-Fehler. Der ÜbergangsschalterNEXARCH_WORKFLOW_APP_ALLOW_HEADER_AUTHkann erst entfallen, wenn alle Frontends mitNEXT_PUBLIC_CORE_API_BASEgebaut sind.🤖 Generated with Claude Code