[
https://issues.apache.org/jira/browse/UNOMI-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130470#comment-18130470
]
Serge Huber commented on UNOMI-1013:
------------------------------------
Moved to 4.0.0: tenants are created and deleted at runtime (often by
provisioning systems), so the operator list from UNOMI-1005 cannot keep up
without a configuration change for every tenant.
Pull request: https://github.com/apache/unomi/pull/921 (merged).
What it does:
* Each tenant lists its own website origins in its {{publicCorsAllowedOrigins}}
property (JSON array or comma-separated string), set by a system administrator
through {{/cxs/tenants}}. Invalid entries are refused with 400.
* A tenant's origins only apply to requests made with that tenant's public key,
for both the visitor cookie and the credentialed CORS response. The operator
list still applies to every tenant.
* A preflight carries no API key, so it is answered for an origin the operator
or any tenant lists; the actual request is checked against its own tenant (the
design from this ticket).
* Tenant origins are kept in memory; requests never load tenants. A change
through {{/cxs/tenants}} applies at once on that node; another node picks up a
new tenant on its first request and other changes within 30 seconds.
* {{org.apache.unomi.public.cors.tenantOrigins}}
({{UNOMI\_PUBLIC\_CORS\_TENANT\_ORIGINS}}, default true) turns tenant lists off.
Also fixed on the way, found in review:
* {{PUT /cxs/tenants/{tenantId}}} saved the body as is. REST never returns key
hashes, so sending back a tenant as read invalidated all of its API keys.
Updates now apply only the settings onto the stored tenant, with a
compare-and-set write, so they never change API keys or the creation date and
never undo a concurrent key regeneration (which is compare-and-set too).
{{PUT}} answers 409 if the tenant keeps changing.
Tests: unit tests for all items of the test list above, plus
TenantTrackerOriginsIT; full IT suite passed locally on Elasticsearch and
OpenSearch.
> Let each tenant list the websites that can use its tracker
> ----------------------------------------------------------
>
> Key: UNOMI-1013
> URL: https://issues.apache.org/jira/browse/UNOMI-1013
> Project: Apache Unomi
> Issue Type: Improvement
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Summary
> With UNOMI-1005, the operator of a Unomi server can list the website origins
> whose pages may send cookies to Unomi. This list is the same for every
> tenant. In a server with many tenants, each tenant has its own websites, and
> the operator has to manage all of them in one place.
> The goal of this ticket is to let each tenant manage its own list, while the
> default stays secure.
> h3. Ways to explore
> * A list of origins in the tenant settings, managed through the tenant API,
> with the same exact matching rules as the operator list.
> * The browser's preflight request does not carry the API key value, so the
> server cannot know the tenant at that point. The preflight could accept an
> origin listed by the operator or by any tenant. The real request, which
> carries the key, is then checked on the server against that tenant's own
> list, and its visitor cookie is not used if the origin is not allowed for
> that tenant.
> * A setting lets the operator turn tenant lists off. Tenant lists can only
> add origins for that tenant; they never change the operator rules.
> * Document how the operator and tenant lists work together.
> h3. How to test
> Automated tests to add:
> * An origin listed by tenant A works with tenant A's key.
> * The same origin with tenant B's key is not tied to the visitor's profile.
> * With tenant lists turned off, only the operator list counts.
> * Origins listed by a tenant follow the same matching rules as the operator
> list.
> * All the tests from UNOMI-1005 still pass.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
