[
https://issues.apache.org/jira/browse/UNOMI-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Sinovassin-Naïk updated UNOMI-980:
-------------------------------------------
Description:
h1. Description
The compatibility mode lets a client written before Unomi 3.1 keep working
with no change on its
side. It currently refuses every request until an operator creates a tenant,
which is a step no
earlier version asked for:
{code:java}
ERROR AuthenticationFilter - V2 compatibility mode: configured default
tenant 'default' does not exist
{code}
Three changes:
1. Create the tenant the mode runs on. A new TenantService.getOrCreateTenant
is synchronized, and it
re-reads the tenant when a concurrent creation wins the race. Several
nodes starting together all
get the tenant, and only one creation happens.
2. Drop the tenant identifier setting. The mode reads the setting in two
places, and both sit inside
the method that runs only when the mode is on. A client from before 3.1
knows no tenant, so it
never names one, and nothing outside the filter reads the value. The
identifier becomes a
constant.
Two unreachable branches go with the setting. Each call site tested the
value for blankness, while
modified() already fell back to "default". The two branches also disagreed:
a blank value denied
every public request on one path, and switched to the system context on the
other.
3. Rename the mode from V2 compatibility to single-tenant compatibility.
Unomi 3.0.0 and 3.0.1 carry
no tenant either, so a 3.0.1 client meets the same wall as a V2 client. The
old name named the
wrong thing. The setting becomes singletenantcompatibility.enabled.
was:to update
> Single-tenant compatibility mode refuses every request until its tenant is
> created by hand
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: UNOMI-980
> URL: https://issues.apache.org/jira/browse/UNOMI-980
> Project: Apache Unomi
> Issue Type: Bug
> Reporter: Jonathan Sinovassin-Naïk
> Priority: Major
>
> h1. Description
>
> The compatibility mode lets a client written before Unomi 3.1 keep working
> with no change on its
> side. It currently refuses every request until an operator creates a
> tenant, which is a step no
> earlier version asked for:
>
> {code:java}
> ERROR AuthenticationFilter - V2 compatibility mode: configured default
> tenant 'default' does not exist
> {code}
>
> Three changes:
>
> 1. Create the tenant the mode runs on. A new
> TenantService.getOrCreateTenant is synchronized, and it
> re-reads the tenant when a concurrent creation wins the race. Several
> nodes starting together all
> get the tenant, and only one creation happens.
> 2. Drop the tenant identifier setting. The mode reads the setting in two
> places, and both sit inside
> the method that runs only when the mode is on. A client from before 3.1
> knows no tenant, so it
> never names one, and nothing outside the filter reads the value. The
> identifier becomes a
> constant.
> Two unreachable branches go with the setting. Each call site tested the
> value for blankness, while
> modified() already fell back to "default". The two branches also
> disagreed: a blank value denied
> every public request on one path, and switched to the system context on
> the other.
> 3. Rename the mode from V2 compatibility to single-tenant compatibility.
> Unomi 3.0.0 and 3.0.1 carry
> no tenant either, so a 3.0.1 client meets the same wall as a V2 client.
> The old name named the
> wrong thing. The setting becomes singletenantcompatibility.enabled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
