potiuk commented on PR #769: URL: https://github.com/apache/unomi/pull/769#issuecomment-4676249136
Thanks @sergehuber — exactly the kind of review that makes the model accurate; all four are going in. **Tenant isolation (UNOMI-139) — agreed, important.** You're right that multi-tenancy is now a first-class boundary (`TenantService`, `Profile.tenantId`, `SecurityService.getTenantEncryptionKey`) and the draft predates it. I'll add the §14 Wave-3 question you suggested verbatim — *can an API client for tenant A read or modify tenant B's profiles, segments, or rules, and is that enforced by Unomi or the integrator?* — and once the PMC confirms enforcement we promote it to a §8 property (or a §10 downstream responsibility if delegated). Genuine new trust boundary; thank you for catching it. **`/eventcollector` — agreed, important.** Adding `EventsCollectorServlet` (`/eventcollector`) alongside `/context.json` everywhere the public ingestion surface appears (§2 component table, §4 trust boundary, §6 inputs, §7 adversary model) so a scanner that lands there routes correctly instead of `MODEL-GAP`. **SECURITY.md** — adding the `[email protected]` routing note. **§5a** — naming the `ThirdPartyServer` key config (server id / key / IP allow-list / allowed event types) in the §14 Wave-2 question so the PMC knows which properties to look up. I'll push the revision with all four folded in. Thanks again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
