[
https://issues.apache.org/jira/browse/UNOMI-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1029:
-------------------------------
Description:
h3. In short
Sites migrating from Unomi 2.x can't choose which tenant compatibility mode
uses: it is always "default". If they migrated their data into another tenant,
2.x trackers and REST admin scripts work on an empty tenant, while GraphQL
admin queries see the real data.
h3. Details
* {{AuthenticationFilter}} uses {{COMPATIBILITY_TENANT_ID = "default"}} for
every request in compatibility mode, auto-creates that tenant, and ignores
{{X-Unomi-Tenant-Id}}. The default tenant setting added by UNOMI-1008
({{org.apache.unomi.rest.authentication.defaultTenantId}} /
{{default.tenant.id}}) is therefore ignored on REST in this mode.
* GraphQL does not know about compatibility mode and always uses that setting.
With the setting changed, REST and GraphQL work on different tenants. The 4.0.0
docs tell operators to keep it at {{default}} while the mode is on.
* Compatibility mode only ever runs on one tenant, so a second setting would
add nothing; reusing the existing one keeps REST and GraphQL consistent.
h3. Fix and test
Replace {{COMPATIBILITY_TENANT_ID}} with the {{defaultTenantId}} setting, read
on each request (still never {{system}}). Log a WARN when compatibility mode
auto-creates its tenant, so a mistyped id is noticed. Update the 4.0.0 comments
and docs that say the mode does not use the setting yet
({{custom.system.properties}}, {{org.apache.unomi.rest.authentication.cfg}},
the {{@AttributeDefinition}} in {{DefaultRestAuthenticationConfig}}, docker
README, {{v2-compatibility-mode.adoc}}, {{migrate-3.0-to-4.0.adoc}},
{{multitenancy.adoc}}, {{security.adoc}}, {{configuration.adoc}}), and say that
changing the setting moves tracking to another tenant and must be the same on
every node. Test: unit test in the compatibility-mode branch with a non-default
value, and make {{SingleTenantCompatibilityModeIT}} read the tenant id from the
config.
was:
h3. In short
Sites migrating from Unomi 2.x can't choose which tenant compatibility mode
uses: it is always "default". If they migrated their data into another tenant,
2.x trackers and REST admin scripts work on an empty tenant, while GraphQL
admin queries see the real data.
h3. Details
* {{AuthenticationFilter}} uses {{COMPATIBILITY_TENANT_ID = "default"}} for
every request in compatibility mode, auto-creates that tenant, and ignores
{{X-Unomi-Tenant-Id}}. The admin default tenant setting added by UNOMI-1008
({{org.apache.unomi.rest.authentication.adminDefaultTenantId}}) is therefore
ignored on REST in this mode.
* GraphQL does not know about compatibility mode and always uses the admin
default tenant. With the setting changed, REST and GraphQL work on different
tenants.
* Compatibility mode only ever runs on one tenant, so a second setting would
add nothing; reusing the existing one keeps REST and GraphQL consistent.
h3. Fix and test
Replace {{COMPATIBILITY_TENANT_ID}} with the admin default tenant setting, read
on each request (still never {{system}}). Log a WARN when compatibility mode
auto-creates its tenant, so a mistyped id is noticed. Update the
compatibility-mode docs to say that changing the setting moves tracking to
another tenant and must be the same on every node. Test: unit test in the
compatibility-mode branch with a non-default value, and make
{{SingleTenantCompatibilityModeIT}} read the tenant id from the config.
Summary: Single-tenant compatibility mode should use the configured
default tenant instead of a hardcoded "default" (was: Single-tenant
compatibility mode should use the configured admin default tenant instead of a
hardcoded "default")
> Single-tenant compatibility mode should use the configured default tenant
> instead of a hardcoded "default"
> ----------------------------------------------------------------------------------------------------------
>
> Key: UNOMI-1029
> URL: https://issues.apache.org/jira/browse/UNOMI-1029
> Project: Apache Unomi
> Issue Type: Improvement
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.1.0
>
>
> h3. In short
> Sites migrating from Unomi 2.x can't choose which tenant compatibility mode
> uses: it is always "default". If they migrated their data into another
> tenant, 2.x trackers and REST admin scripts work on an empty tenant, while
> GraphQL admin queries see the real data.
> h3. Details
> * {{AuthenticationFilter}} uses {{COMPATIBILITY_TENANT_ID = "default"}} for
> every request in compatibility mode, auto-creates that tenant, and ignores
> {{X-Unomi-Tenant-Id}}. The default tenant setting added by UNOMI-1008
> ({{org.apache.unomi.rest.authentication.defaultTenantId}} /
> {{default.tenant.id}}) is therefore ignored on REST in this mode.
> * GraphQL does not know about compatibility mode and always uses that
> setting. With the setting changed, REST and GraphQL work on different
> tenants. The 4.0.0 docs tell operators to keep it at {{default}} while the
> mode is on.
> * Compatibility mode only ever runs on one tenant, so a second setting would
> add nothing; reusing the existing one keeps REST and GraphQL consistent.
> h3. Fix and test
> Replace {{COMPATIBILITY_TENANT_ID}} with the {{defaultTenantId}} setting,
> read on each request (still never {{system}}). Log a WARN when compatibility
> mode auto-creates its tenant, so a mistyped id is noticed. Update the 4.0.0
> comments and docs that say the mode does not use the setting yet
> ({{custom.system.properties}}, {{org.apache.unomi.rest.authentication.cfg}},
> the {{@AttributeDefinition}} in {{DefaultRestAuthenticationConfig}}, docker
> README, {{v2-compatibility-mode.adoc}}, {{migrate-3.0-to-4.0.adoc}},
> {{multitenancy.adoc}}, {{security.adoc}}, {{configuration.adoc}}), and say
> that changing the setting moves tracking to another tenant and must be the
> same on every node. Test: unit test in the compatibility-mode branch with a
> non-default value, and make {{SingleTenantCompatibilityModeIT}} read the
> tenant id from the config.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
