[
https://issues.apache.org/jira/browse/UNOMI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123482#comment-18123482
]
Serge Huber commented on UNOMI-1005:
------------------------------------
Decision: a flexible setup that keeps existing clients and deployments working,
with a secure default (no other origin may send cookies until the operator
lists it) and documentation on how to configure it safely. Details are under
"Decided approach" in the description.
Open question: should tenants be able to define their own list of origins? Each
tenant has its own websites, so it would make sense. One constraint to keep in
mind: the browser's preflight request does not carry the API key value, so the
server cannot know the tenant at that point. A possible design is that the
preflight accepts an origin listed by the operator or by any tenant, and the
real request, which carries the key, is then checked on the server against that
tenant's own list. Operators should be able to turn tenant lists off.
> The web tracker and the server disagree on cookies across sites
> ---------------------------------------------------------------
>
> Key: UNOMI-1005
> URL: https://issues.apache.org/jira/browse/UNOMI-1005
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> In 4.0, the context.json, eventcollector and client endpoints no longer allow
> cookies on requests that come from another site. This was an intended change.
> But the web tracker shipped with Unomi still sends its requests with cookies.
> When the website and Unomi are on different domains, the browser blocks the
> answer, so tracking stops working. It worked in 3.0.1.
> Note: the visitor cookie uses SameSite=Lax, so browsers only send it within
> the same site.
> The goal of this ticket is a flexible setup that works for existing clients
> and deployments, with a secure default and clear documentation on how to
> configure it safely.
> h3. Decided approach
> * Secure default: with no configuration, no other origin may send cookies, as
> in 4.0 today. Same-site setups work without any change.
> * An operator setting (configuration file and environment variable) lists the
> website origins that may send cookies. For a listed origin, the answer allows
> cookies, names only that origin, and includes "Vary: Origin". Preflight
> requests follow the same rule.
> * Origins are compared exactly: scheme, host and port. Wildcards are not
> supported in this version. Cookies are never allowed together with "allow all
> origins", and the request's origin is never copied back unless it is listed.
> * The server also checks the origin itself: it does not use the visitor
> cookie of a request that comes from an origin that is not allowed. Browser
> rules alone only stop the page from reading the answer; they do not stop the
> request from being handled.
> * Requests without an Origin header (same-site pages, server-to-server calls)
> behave as today.
> * Existing clients keep working: the shipped tracker needs no change once its
> site is listed. The tracker gets an option to send requests without cookies,
> for setups that do not need them.
> * The visitor cookie stays SameSite=Lax by default. A deployment that really
> needs cookies across different sites may set SameSite=None, but only together
> with Secure and a non-empty list of origins. The documentation explains that
> browsers increasingly block such cookies and recommends a same-site setup.
> * Do not move visitor identity into the request body or browser storage.
> UNOMI-975 ties a public request to the profile of its own cookie.
> * Document the setting with a secure example, the same-site setup, and what
> not to do.
> * Per-tenant lists of origins are discussed in the comments.
> h3. How to test
> Manual check: serve a test page from a listed origin on another domain, load
> the shipped tracker, and check that context.json and event requests succeed
> in the browser. Repeat from an origin that is not listed and check that it
> fails.
> Automated tests to add, extending the public tracker CORS tests:
> * With the default settings, no origin is allowed to send cookies.
> * A listed origin is allowed, the answer names only that origin, and includes
> "Vary: Origin". The same for preflight.
> * An unlisted origin, the same host with another scheme or port, a subdomain
> of a listed origin, and the "null" origin are all refused.
> * Cookies are never allowed together with "allow all origins".
> * A request with a visitor cookie from an origin that is not allowed is not
> tied to that visitor's profile.
> * A request without an Origin header behaves as before.
> * The environment variable reaches the setting.
> * SameSite=None is refused without Secure or without a list of origins. The
> default cookie keeps SameSite=Lax.
> * The tracker option without cookies works with the default server settings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
