[
https://issues.apache.org/jira/browse/UNOMI-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1001:
-------------------------------
Description:
h3. Summary
Single-tenant compatibility mode helps existing installations move to 4.0
without changes. In 3.0, a trusted server that sent the X-Unomi-Peer header
could:
* merge profiles on login,
* choose the profile id in a request,
* set event ids,
* update other profiles' properties, segments, scores and consents.
In 4.0 compatibility mode, the header is still checked before an event is
accepted. But the server is then treated like a normal visitor, so all of the
features above stop working. The documentation of the mode says it behaves
"like V2".
The goal of this ticket is that a server that worked with 3.0 keeps working in
compatibility mode, or that the documentation says clearly what changes.
h3. Ways to explore
* Preferred: document that 3.0 third-party servers should move to a tenant
private API key, which already provides these features. Update the
compatibility mode page.
* If trust based on X-Unomi-Peer is restored, keep it narrow:
** only in compatibility mode, and only on public endpoints,
** only when both the key and the caller's IP address match,
** only the abilities that 3.0 gave a third-party server, for its allowed event
types, never administrator rights,
** only for a key the operator has set, never the example value from the
shipped configuration,
** without changing the checks from UNOMI-975 and UNOMI-978 in normal mode.
* Document how the caller IP is seen behind a reverse proxy.
h3. How to test
In compatibility mode, send requests from a configured third-party server using
X-Unomi-Peer. Check that profile merge on login, a request with a profileId,
and an event with an itemId work as they did in 3.0, or that the documentation
describes the new way to do this.
was:
h3. Summary
Single-tenant compatibility mode helps existing installations move to 4.0
without changes. In 3.0, a trusted server that sent the X-Unomi-Peer header
could:
* merge profiles on login,
* choose the profile id in a request,
* set event ids,
* update other profiles' properties, segments, scores and consents.
In 4.0 compatibility mode, the header is still checked before an event is
accepted. But the server is then treated like a normal visitor, so all of the
features above stop working. The documentation of the mode says it behaves
"like V2".
The goal of this ticket is that a server that worked with 3.0 keeps working in
compatibility mode, or that the documentation says clearly what changes.
h3. Ways to explore
* Preferred: document that 3.0 third-party servers should move to a tenant
private API key, which already provides these features. Update the
compatibility mode page.
* If trust based on X-Unomi-Peer is restored, keep it narrow:
*** only in compatibility mode, and only on public endpoints,
*** only when both the key and the caller's IP address match,
*** only the abilities that 3.0 gave a third-party server, for its allowed
event types, never administrator rights,
*** only for a key the operator has set, never the example value from the
shipped configuration,
*** without changing the checks from UNOMI-975 and UNOMI-978 in normal mode.
* Document how the caller IP is seen behind a reverse proxy.
h3. How to test
In compatibility mode, send requests from a configured third-party server using
X-Unomi-Peer. Check that profile merge on login, a request with a profileId,
and an event with an itemId work as they did in 3.0, or that the documentation
describes the new way to do this.
> In compatibility mode, 3.0 third-party servers lose features
> ------------------------------------------------------------
>
> Key: UNOMI-1001
> URL: https://issues.apache.org/jira/browse/UNOMI-1001
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Blocker
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> Single-tenant compatibility mode helps existing installations move to 4.0
> without changes. In 3.0, a trusted server that sent the X-Unomi-Peer header
> could:
> * merge profiles on login,
> * choose the profile id in a request,
> * set event ids,
> * update other profiles' properties, segments, scores and consents.
> In 4.0 compatibility mode, the header is still checked before an event is
> accepted. But the server is then treated like a normal visitor, so all of the
> features above stop working. The documentation of the mode says it behaves
> "like V2".
> The goal of this ticket is that a server that worked with 3.0 keeps working
> in compatibility mode, or that the documentation says clearly what changes.
> h3. Ways to explore
> * Preferred: document that 3.0 third-party servers should move to a tenant
> private API key, which already provides these features. Update the
> compatibility mode page.
> * If trust based on X-Unomi-Peer is restored, keep it narrow:
> ** only in compatibility mode, and only on public endpoints,
> ** only when both the key and the caller's IP address match,
> ** only the abilities that 3.0 gave a third-party server, for its allowed
> event types, never administrator rights,
> ** only for a key the operator has set, never the example value from the
> shipped configuration,
> ** without changing the checks from UNOMI-975 and UNOMI-978 in normal mode.
> * Document how the caller IP is seen behind a reverse proxy.
> h3. How to test
> In compatibility mode, send requests from a configured third-party server
> using X-Unomi-Peer. Check that profile merge on login, a request with a
> profileId, and an event with an itemId work as they did in 3.0, or that the
> documentation describes the new way to do this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
