[
https://issues.apache.org/jira/browse/UNOMI-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1019:
-------------------------------
Fix Version/s: unomi-4.0.0
Affects Version/s: unomi-tracker-1.5.0
(was: unomi-tracker-1.6.0)
Description:
h3. Summary
Unomi 4 can host several separate customers (tenants) on one server, but the
Unomi web tracker cannot yet say which customer a website belongs to. As a
result, websites cannot use the tracker with a multi-tenant Unomi 4 server;
they only work with older servers or with Unomi 4 set to behave like a
single-customer server. The goal is one tracker that works with all Unomi
versions, chosen by its configuration.
Technical detail: in 4.0, context.json and eventcollector need a tenant public
API key in the X-Unomi-Api-Key header, unless the single-tenant compatibility
mode is on. The web tracker (apache-unomi-tracker) cannot send this header. So
it only works with Unomi 2, Unomi 3, or Unomi 4 in compatibility mode, where
every request goes to the default tenant. With a multi-tenant server it gets
401 answers.
The manual already tells readers to use the NPM tracker to send the key
(web-tracker.adoc, tutorial.adoc), but the tracker does not support it yet. The
tracker bundled with Unomi (extensions/web-tracker) repackages the NPM tracker,
so it has the same limit.
The goal of this ticket is that the same tracker works with Unomi 2, Unomi 3
and Unomi 4 multi-tenant, chosen by configuration.
h3. Decided approach
* A new optional setting, wemInitConfig.apiKey. When it is set, the tracker
sends it as X-Unomi-Api-Key on context.json and eventcollector requests. When
it is not set, requests are exactly as today.
* No tenant ID setting. On public endpoints the server finds the tenant from
the public key alone. X-Unomi-Tenant-Id is only used on private endpoints.
* Only the public key goes in the tracker. The page configuration is visible to
every visitor, so the documentation must say never to use a private key there.
* Older servers keep working when a key is set. Their CORS settings allow any
request header, so the preflight passes and the header is ignored. In
compatibility mode the 4.0 server ignores the key on public endpoints.
* Released as tracker 2.0.0, a drop-in replacement for 1.x. The 1.x line
(branch 1\_x) keeps supporting Unomi 2.x and 3.x, with fixes only.
h3. Known cost
* The custom header makes the browser send a CORS preflight. The tracker uses
text/plain today to avoid one.
* Neither 2.x nor 4.0 sets Access-Control-Max-Age, so browsers keep the
preflight result only briefly and send one before almost every request. Setting
a max age on the public endpoints could be a separate server ticket.
* A key can be combined with sendCredentials: false (UNOMI-1005) for sites that
do not need the visitor cookie.
h3. Changes
* Tracker: https://github.com/apache/unomi-tracker/pull/27 (apiKey,
documentation, and browser tests against Unomi 2.x, 3.x and 4.x with yarn
test:servers).
* Manual: https://github.com/apache/unomi/pull/925 (web-tracker.adoc,
tutorial.adoc, the JavaScript tracker guide, the 3.0 to 4.0 migration guide and
configuration.adoc describe how to configure the tracker for each Unomi
version).
* After the tracker 2.0.0 release: update extensions/web-tracker from 1.4.0 to
2.0.0 and add apiKey to its sample page.
h3. How to test
Automated tests in the tracker:
* No header is sent when apiKey is not set or is empty.
* The header is sent with the configured value when apiKey is set.
* The other request headers are unchanged.
Manual checks:
* A page with apiKey loads context.json from another origin against a 4.0
multi-tenant server, and the events go to that tenant.
* The same page works against a 2.x server and against 4.0 in compatibility
mode.
* A page without apiKey gets 401 from a 4.0 multi-tenant server and works in
compatibility mode.
was:
h3. Summary
In 4.0, context.json and eventcollector need a tenant public API key in the
X-Unomi-Api-Key header, unless the single-tenant compatibility mode is on. The
web tracker (apache-unomi-tracker) cannot send this header. So it only works
with Unomi 2, Unomi 3, or Unomi 4 in compatibility mode, where every request
goes to the default tenant. With a multi-tenant server it gets 401 answers.
The manual already tells readers to use the NPM tracker to send the key
(web-tracker.adoc, tutorial.adoc), but the tracker does not support it yet. The
tracker bundled with Unomi (extensions/web-tracker) repackages the NPM tracker,
so it has the same limit.
The goal of this ticket is that the same tracker works with Unomi 2, Unomi 3
and Unomi 4 multi-tenant, chosen by configuration.
h3. Decided approach
* A new optional setting, wemInitConfig.apiKey. When it is set, the tracker
sends it as X-Unomi-Api-Key on context.json and eventcollector requests. When
it is not set, requests are exactly as today.
* No tenant ID setting. On public endpoints the server finds the tenant from
the public key alone. X-Unomi-Tenant-Id is only used on private endpoints.
* Only the public key goes in the tracker. The page configuration is visible to
every visitor, so the documentation must say never to use a private key there.
* Older servers keep working when a key is set. Their CORS settings allow any
request header, so the preflight passes and the header is ignored. In
compatibility mode the 4.0 server ignores the key on public endpoints.
h3. Known cost
* The custom header makes the browser send a CORS preflight. The tracker uses
text/plain today to avoid one.
* Neither 2.x nor 4.0 sets Access-Control-Max-Age, so browsers keep the
preflight result only briefly and send one before almost every request. Setting
a max age on the public endpoints could be a separate server ticket.
* A key can be combined with sendCredentials: false (UNOMI-1005) for sites that
do not need the visitor cookie.
h3. Follow-ups in apache/unomi
* Update extensions/web-tracker to the tracker release that includes this, and
let its page configuration pass apiKey.
* Update web-tracker.adoc, tutorial.adoc and the JavaScript tracker guide so
that they describe the apiKey setting.
h3. How to test
Automated tests in the tracker:
* No header is sent when apiKey is not set or is empty.
* The header is sent with the configured value when apiKey is set.
* The other request headers are unchanged.
Manual checks:
* A page with apiKey loads context.json from another origin against a 4.0
multi-tenant server, and the events go to that tenant.
* The same page works against a 2.x server and against 4.0 in compatibility
mode.
* A page without apiKey gets 401 from a 4.0 multi-tenant server and works in
compatibility mode.
> Make unomi-tracker compatible with both V2/V3 and V4
> ----------------------------------------------------
>
> Key: UNOMI-1019
> URL: https://issues.apache.org/jira/browse/UNOMI-1019
> Project: Apache Unomi
> Issue Type: Improvement
> Components: unomi-tracker
> Affects Versions: unomi-tracker-1.5.0
> Reporter: Serge Huber
> Assignee: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0, unomi-tracker-2.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Summary
> Unomi 4 can host several separate customers (tenants) on one server, but the
> Unomi web tracker cannot yet say which customer a website belongs to. As a
> result, websites cannot use the tracker with a multi-tenant Unomi 4 server;
> they only work with older servers or with Unomi 4 set to behave like a
> single-customer server. The goal is one tracker that works with all Unomi
> versions, chosen by its configuration.
> Technical detail: in 4.0, context.json and eventcollector need a tenant
> public API key in the X-Unomi-Api-Key header, unless the single-tenant
> compatibility mode is on. The web tracker (apache-unomi-tracker) cannot send
> this header. So it only works with Unomi 2, Unomi 3, or Unomi 4 in
> compatibility mode, where every request goes to the default tenant. With a
> multi-tenant server it gets 401 answers.
> The manual already tells readers to use the NPM tracker to send the key
> (web-tracker.adoc, tutorial.adoc), but the tracker does not support it yet.
> The tracker bundled with Unomi (extensions/web-tracker) repackages the NPM
> tracker, so it has the same limit.
> The goal of this ticket is that the same tracker works with Unomi 2, Unomi 3
> and Unomi 4 multi-tenant, chosen by configuration.
> h3. Decided approach
> * A new optional setting, wemInitConfig.apiKey. When it is set, the tracker
> sends it as X-Unomi-Api-Key on context.json and eventcollector requests. When
> it is not set, requests are exactly as today.
> * No tenant ID setting. On public endpoints the server finds the tenant from
> the public key alone. X-Unomi-Tenant-Id is only used on private endpoints.
> * Only the public key goes in the tracker. The page configuration is visible
> to every visitor, so the documentation must say never to use a private key
> there.
> * Older servers keep working when a key is set. Their CORS settings allow any
> request header, so the preflight passes and the header is ignored. In
> compatibility mode the 4.0 server ignores the key on public endpoints.
> * Released as tracker 2.0.0, a drop-in replacement for 1.x. The 1.x line
> (branch 1\_x) keeps supporting Unomi 2.x and 3.x, with fixes only.
> h3. Known cost
> * The custom header makes the browser send a CORS preflight. The tracker uses
> text/plain today to avoid one.
> * Neither 2.x nor 4.0 sets Access-Control-Max-Age, so browsers keep the
> preflight result only briefly and send one before almost every request.
> Setting a max age on the public endpoints could be a separate server ticket.
> * A key can be combined with sendCredentials: false (UNOMI-1005) for sites
> that do not need the visitor cookie.
> h3. Changes
> * Tracker: https://github.com/apache/unomi-tracker/pull/27 (apiKey,
> documentation, and browser tests against Unomi 2.x, 3.x and 4.x with yarn
> test:servers).
> * Manual: https://github.com/apache/unomi/pull/925 (web-tracker.adoc,
> tutorial.adoc, the JavaScript tracker guide, the 3.0 to 4.0 migration guide
> and configuration.adoc describe how to configure the tracker for each Unomi
> version).
> * After the tracker 2.0.0 release: update extensions/web-tracker from 1.4.0
> to 2.0.0 and add apiKey to its sample page.
> h3. How to test
> Automated tests in the tracker:
> * No header is sent when apiKey is not set or is empty.
> * The header is sent with the configured value when apiKey is set.
> * The other request headers are unchanged.
> Manual checks:
> * A page with apiKey loads context.json from another origin against a 4.0
> multi-tenant server, and the events go to that tenant.
> * The same page works against a 2.x server and against 4.0 in compatibility
> mode.
> * A page without apiKey gets 401 from a 4.0 multi-tenant server and works in
> compatibility mode.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
