[
https://issues.apache.org/jira/browse/UNOMI-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1008:
-------------------------------
Description:
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.
was:
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 clear behaviour, matched by the documentation.
h3. Ways to explore
* Answer with a clear error when the tenant id does not exist. Check the tenant
only after authentication succeeds.
* Decide what a request without the header should do, and document it in one
place.
* Add the header to the examples in the migration guide.
h3. How to test
Manual check: send an admin request with a tenant id that does not exist, and
one without the header. Check that each result matches the documentation.
Automated tests to add. Each must fail on the 4.0.0 release candidate and pass
once the fix is in:
* A unit test of the authentication filter: an admin request with an existing
tenant id works in that tenant; with an unknown tenant id it gets the
documented error; without the header it gets the documented behaviour.
* A test that a request with wrong credentials gets the same answer whether the
tenant id exists or not.
* An integration test that an admin request with the tenant header sees that
tenant's data, and only that tenant's data.
* The same checks for the tenant management endpoints, which use the same logic.
> 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)
