[
https://issues.apache.org/jira/browse/UNOMI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123484#comment-18123484
]
Serge Huber commented on UNOMI-1008:
------------------------------------
Decision: admin requests without a tenant header keep working for Unomi 3.0
scripts and tools, using a configurable tenant that defaults to "default".
Working in the "system" tenant becomes an explicit choice for full
administrators only. Details and tests are under "Decided approach" in the
description.
> Admin requests without a tenant header do not see migrated data
> ---------------------------------------------------------------
>
> Key: UNOMI-1008
> URL: https://issues.apache.org/jira/browse/UNOMI-1008
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> After a migration from 3.0, all the data is in the "default" tenant. An admin
> request with Basic authentication and no X-Unomi-Tenant-Id header does not
> see this data, and nothing tells the user why. A request with a tenant id
> that does not exist also gives no error.
> The migration guide shows such a request without the header, and two manual
> pages disagree about what happens: one says the header is optional, another
> says that an unknown tenant gives an error 401.
> The goal of this ticket is that admin scripts and tools written for Unomi 3.0
> keep working after the migration, with clear and documented behaviour.
> h3. Decided approach
> * Unomi 3.0 clients call admin endpoints without a tenant header. A setting
> names the tenant used when an admin request has no header. Its default is
> "default", where the migration puts the data, so 3.0 scripts keep working. If
> that tenant does not exist, the request gets a clear error.
> * Working in the "system" tenant must be an explicit choice, with the header,
> and open only to full administrators.
> * An unknown tenant id gets a clear error, checked only after authentication
> succeeds. A request with wrong credentials gets the same answer whether the
> tenant exists or not.
> * The tenant management endpoints follow the same rules.
> * Document the behaviour in one place, and fix the examples in the migration
> guide.
> h3. How to test
> Manual check: after a migration, run an admin request without the header and
> check that it sees the migrated data. Run one with an unknown tenant id and
> check the error.
> Automated tests to add:
> * Without the header, an admin request works in the tenant named by the
> setting, and sees that tenant's data only.
> * If that tenant does not exist, the request gets the documented error.
> * With the header of an existing tenant, the request works in that tenant
> only.
> * With an unknown tenant id, the request gets the documented error.
> * Wrong credentials give the same answer whether the tenant exists or not.
> * Only full administrators can work in the "system" tenant, and only with the
> header.
> * The same checks for the tenant management endpoints.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
