As of mid-July 2020, the Chrome (and Chromium) stable release channel has started to disable cross-site cookies by default. Mozilla Firefox has pushed this change to their beta channel and will likely release it to the stable channel soon. This change affects any DHIS2 application running on a different domain than the DHIS2 server instance, including applications running on localhost in development. It does not affect cross-site API requests which use Basic or OAuth authentication headers, as those do not rely on cookies for authentication.
Basically, browsers are starting to block, by default, most cookies (which typically contain sensitive information such as login session tokens) to a domain which does not match the current URL of the site visited in the browser. The SERVER (not the browser) must set a specific attribute on the cookie (called
SameSite to have the value
None) if the cookie is safe to include in cross-domain requests. The attribute
Secure, which requires that the cookie only be sent over encrypted HTTPS connections, MUST also be set on the Cookie because it is now required for
SameSite=None cookies. DHIS2 does not set these attributes on its authentication cookies. As of mid-July, popular browsers like Chrome and Firefox are beginning to enforce these rules.
Confused? Learn more here
The vast majority of DHIS2 users and implementers will not be affected by this issue. DHIS2 applications which are directly installed into a DHIS2 instance (either core applications or custom ones installed through the App Management app) will continue to work without any interruptions.
However, applications running on another server under a different domain will stop functioning in browsers which implement this new security feature. The most common place this occurs is during application development when your local application (running at
http://localhost:3000, for instance) attempts to connect and authenticate with a remote DHIS2 server (running at
https://dhis2.myorg.com, for instance). When this happens, authentication will fail and the developer will see repeated HTTP 401 (
Error: Unauthorized) errors in the developer console. A warning will also appear, at least in Chrome, similar to the following (it also appears in older versions which do not yet implement the feature):
A cookie associated with a cross-site resource at http://dhis2.org/ was set without the
SameSiteattribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with
Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.
In very rare cases, a production DHIS2 application might be running on a different domain than the DHIS2 server. If this issue is affecting a production application in your environment please let us know as soon as possible by opening a Jira ticket!
By far the most secure way to work around this issue during application development is to run a local instance of DHIS2 against which you can test your application. You can easily spin up one or more DHIS2 instances locally using Docker and the
d2 cluster command of the DHIS2 CLI
It is possible to disable the default SameSite=Lax behavior in Chrome and Chromium by setting the "SameSite by default cookies" flag (chrome://flags/#same-site-by-default-cookies) to Disabled. Note that this disables legitimate security behaviors in your browser, so proceed with caution! We recommend that you only disable this flag when actively debugging a DHIS2 application
NOTE Applications installed directly on a DHIS2 application (using the DHIS2 App Management app) will be available on the same domain as the DHIS2 instance, and so are not affected by this issue
SameSite=None; Secure attributes on the DHIS2 authentication cookie and to run the DHIS2 instance with SSL/TLS enabled (so that it is only accessible over HTTPS). DHIS2 does not currently support this behavior by default, so it is necessary to modify the server's cookie responses in a gateway such as NGINX or Apache. If you are hosting a production application outside of your DHIS2 instance and affected by this issue please reach out to the DHIS2 core team so that we can be made aware of use-cases and can help you work around the issue with a gateway setup
In short, we aren't sure if or how we will change the default behavior or DHIS2 cookie authentication yet. We are evaluating options for secure cross-domain authentication and simplified application development workflows, and will share more when we have more information.