[
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-tracker-2.0.0
(was: unomi-tracker-1.6.0)
> 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.6.0
> Reporter: Serge Huber
> Assignee: Serge Huber
> Priority: Major
> Fix For: unomi-tracker-2.0.0
>
>
> 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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
