[
https://issues.apache.org/jira/browse/UNOMI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130471#comment-18130471
]
Serge Huber commented on UNOMI-1005:
------------------------------------
Notes on what was merged in https://github.com/apache/unomi/pull/920, where it
differs from the decided approach above:
* "Same-site setups work without any change" holds for the same origin (a
reverse proxy serving the website and /cxs on one host). A website on another
subdomain must be listed: browsers only accept a credentialed answer that names
the exact origin, and accepting all same-site origins would need the
public-suffix list and would let any subdomain act as the visitor.
* "Requests without an Origin header behave as today" holds for
server-to-server calls. A browser request without Origin but with
Sec-Fetch-Site cross-site or same-site (another site's [script] or [img]) is
served without the visitor cookie. Listed websites that embed context.js with a
[script] tag (single-tenant compatibility mode) can be recognised by their
Referer with the opt-in org.apache.unomi.public.cors.matchReferer; it is off by
default because a sandboxed frame on a listed page inherits that page's Referer.
* A request that may not use the cookie also receives no Set-Cookie, so it
cannot replace or plant the visitor's profile id.
* Per-tenant lists (UNOMI-1013) were moved to 4.0.0 for deployments that create
tenants at runtime: https://github.com/apache/unomi/pull/921
> 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
> Assignee: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
(v10.3.26#10030026)
