[
https://issues.apache.org/jira/browse/UNOMI-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1005:
-------------------------------
Description:
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.
was:
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 that the shipped tracker works with the shipped
server when they run on different domains, or that the documentation says
clearly which setups are supported.
h3. Ways to explore
* Preferred: document a same-site setup, with Unomi on a subdomain of the
website or behind the website's reverse proxy.
* If cookies are allowed again for other origins, allow them only for an
explicit list set by the operator. Compare scheme, host and port exactly, keep
the list empty by default, and never combine it with "allow all origins" or
with copying the request's origin back. Send "Vary: Origin".
* Do not change the cookie's SameSite setting.
* Do not move visitor identity into the request body or browser storage to get
around this. UNOMI-975 ties a public request to the profile of its own cookie.
h3. How to test
Manual check: serve a test page from a domain other than the Unomi server's,
load the shipped tracker, and check that context.json and event requests
succeed in the browser, or that the documented setup works.
Automated tests to add:
* A test that the shipped tracker and the server agree: the tracker only sends
cookies when the server is set up to accept them.
* A test that the visitor cookie keeps its SameSite setting.
If an allow-list of origins is added, extend 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",
* 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".
> 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)
