We are in the process of upgrading our DHIS2 from 2.40.4.1 to 2.40.9.1.
Issue Description: On our local servers which are hosted on a linux VM on Windows Machine(Host) we are facing the problem while accessing Capture App and Browser Cache Cleaner on http:// while it is accessible over https:// .
We are receiving below error on Capture App
The application could not be loaded. A possible reason for this is that the browser or mode (e.g. privacy mode) is not supported. See log for details.
This is expected behavior in newer DHIS2 versions, including 2.40.9.1. The issue is not related to the Linux VM or the Windows host.
The error you are seeing (window.crypto.subtle is undefined) occurs because the Capture App and Cache Cleaner now rely on the browser WebCrypto API, which is only available in a secure context. This means the apps will work when DHIS2 is accessed over HTTPS (or http://localhost), but will fail when accessed over plain HTTP using an IP address or hostname.
This is why the Capture App loads correctly over HTTPS but not over HTTP.
The recommended solution is to enforce HTTPS access to the DHIS2 instance (for example, via Nginx/Apache or a load balancer) and redirect HTTP traffic to HTTPS. If you are using a reverse proxy, make sure the correct proxy headers are set so DHIS2 recognizes the request as HTTPS.
Thanks for confirming this as the expected behaviour. Can you confirm if this is an intended change. If yes, why only scoped till Capture and Cache Cleaner App? Does that mean in future patches we can expect it for other apps? Also, if the information is handy can you help me understand if there is a specific version of the apps where the apps are relying on browser’s webcrypto api. For instance the default version with DHIS2 2.40.9.1 for Capture is 103.3.1 where i see this behaviour but with the 100.69.2 its working. Likewise if you have the version details of the apps like Maintenance, Dashboards, Data Visualiser, etc where this applies would be helpful and help us plan better and wouldn’t come as a surprise.
Is this an intended change?
Yes. This behavior is driven by modern browser security standards. Once an app starts using the browser WebCrypto API (window.crypto.subtle), browsers require a secure context. DHIS2 is aligning with this, so it is expected rather than a regression.
Why is this currently limited to Capture and Cache Cleaner?
These two apps are among the first DHIS2 apps to introduce functionality that depends on WebCrypto (for client-side hashing / security-related operations). Other apps do not yet rely on this API, which is why they still work over HTTP. This is due to implementation differences, not an explicit restriction.
Should we expect this in other apps in the future?
Yes, very likely. As other DHIS2 apps adopt similar frontend security patterns or browser APIs, they will inherit the same secure-context requirement. Planning for HTTPS-only access is the safest approach.
Is there a specific app version where this started?
From what i observed behavior:
Capture 100.69.2 works over HTTP because it does not rely on WebCrypto.
Capture 103.3.1 (bundled with DHIS2 2.40.9.1) introduces usage of crypto.subtle, which enforces HTTPS.
I don’t have an official matrix listing the exact versions for other apps (Maintenance, Dashboards, Data Visualizer, etc.) where this will apply, but at the moment Capture and Cache Cleaner are the primary ones affected.
But gladly @Shapr0019 clarified what is going on - thanks a lot!
Vishwanideep, if the issue is solved please mark the post that’s the solution.
If you need to do this quickly only for testing purposes, you can bypass this SECURITY feature (proceed with caution and make sure to disable it after):
Click to view insecure way to bypass the secure context
Go to chrome://flags/#unsafely-treat-insecure-origin-as-secure
