refactor(sse): narrow canonical audience scopes
This commit is contained in:
@@ -5,6 +5,7 @@
|
||||
- SSE subscriptions are derived on the server from the authenticated database user.
|
||||
- Clients do not provide arbitrary audience lists.
|
||||
- Every scoped event declares its audience explicitly.
|
||||
- Invalid audience strings fail fast in the event bus.
|
||||
- Unscoped delivery is disabled for authenticated timeline subscriptions.
|
||||
|
||||
## Audience Model
|
||||
@@ -12,10 +13,11 @@
|
||||
Supported canonical audiences:
|
||||
|
||||
- `user:<userId>` for personal notifications and tasks
|
||||
- `role:<systemRole>` for role-wide operational events
|
||||
- `permission:<permissionKey>` for explicit capability audiences
|
||||
- `resource:<resourceId>` for self-service or affected-resource updates
|
||||
|
||||
Any other prefix is invalid and must be rejected instead of being accepted silently.
|
||||
|
||||
## Subscription Flow
|
||||
|
||||
1. The web SSE route authenticates the session and loads the database user.
|
||||
@@ -28,7 +30,7 @@ Supported canonical audiences:
|
||||
|
||||
- Personal events such as notifications must target `user:<userId>`.
|
||||
- Planning events may target both `permission:manageAllocations` and affected `resource:<resourceId>` audiences.
|
||||
- Broad operational events must use the smallest real audience that matches the use case.
|
||||
- Broad operational events must use the smallest real audience that matches the use case, typically `permission:*` rather than role fan-out.
|
||||
|
||||
## Contract Tests
|
||||
|
||||
|
||||
Reference in New Issue
Block a user