Hello,
I’ve noticed that users are being logged out of the app after a short period of inactivity. This has been affecting their workflow, especially during consultations.
Is there a way to configure or increase the session timeout duration to allow users to stay logged in longer?
CHT Version 4.15.0
Any guidance on this would be appreciated.
Hi @Kenyuri
The session timeout should be one year by default. unless you have made changes to your couchdb settings, you should never see users being logged out.
Thinking about other possibilities, you would see the same behavior is something changes the user’s password.
Can you please confirm whether you’ve made changes to cht installation?
No changes were made. When I curl to the couchdb it only shows authentication_db and secret and I think CouchDB is using its default session timeout
curl http://admin:password@localhost:5984/_node/_local/_config/couch_httpd_auth
default session timeout
This leads me to believe that you are not running the CHT version of CouchDb.
How did you deploy 4.15? Can you please share the value you get from that endpoint? (please remove the secret value).
We did a custom installation on Openshift. The couchdb was installed using helm chart
That explains it. You should always use the CHT image for CouchDb instead of vanilla CouchDb.
I have resolved the issue by defining the CouchDB session timeout
I ran this command
curl -X PUT http://admin:yourpassword@localhost:5984/_node/_local/_config/couch_httpd_auth/timeout -d ‘“28800”’
28800 is 8 hours in seconds.
Verified after setting the timeout by running this command;
curl http://admin:yourpassword@localhost:5984/_node/_local/_config/couch_httpd_auth
The session timeout is not the only change that the CHT CouchDb image brings.
I strongly advise you always use the CHT CouchDb image.
The main reason to use the CHT CouchDb image is for compatibility with the CHT.
We have very elaborate end-to-end testing suites for the CHT that all run over a specific CouchDb setup - this means a specific version of CouchDb with a specific configuration. We also thoroughly test compatibility when we upgrade the version of CouchDb we use for the CHT image.
Often it has happened that we had to make changes to either the code or the CouchDb configuration to support changes made in CouchDb upstream. And we know there are some configuration combinations that the CHT is incompatible with.
It can happen that we make future to the CHT code that becomes incompatible with vanilla CouchDb. We will include these changes in our image and make sure that the upgrade is seamless, however this will not be the case if someone uses a different CouchDb image than the CHT one.
The second reason is to get the configuration that we have tweaked either for performance, ease of use or to fix certain unwanted behaviors. We update this configuration when we find necessary changes for functionality, or for performance improvements.
The third reason is that we baked in clustering in the image. Creating a working CouchDb cluster that the CHT can work with is not straightforward, and our image has a script that automatically creates this functional cluster.
The idea is that you can find all sorts of unwanted surprises if you use default (vanilla) CouchDb. This session timeout is just one example.
Hello Diana,
our goal is to deploy couchdb on Kubernetes and using official Helm image that would allow us to deploy a cluster easily.
From what I can see in cht image, the main and “only” modification is done here:
So if we replicate these configurations in our helm config we will have the same setup ( and we will need to adapt as from a security point of view, a session could not be valid 1 year)
Btw, we found an issue in the cht-core/blob/master/couchdb/10-docker-default.ini:
in couchdb version 3.2, secret moved from couch_httpd_auth to chttpd_auth .
Does this modifications should be applied to cht-core/couchdb and cht-core/api ?
I’m not sure where the limitation is when deploying CouchDb via helm chart.
If you go this path, of using your own CouchDb image, further upgrades are not safe and you will have to employ manual steps to apply all the changes, which might not be trivial.
I strongly advise you use the CHT-Core CouchDb image.
Excellent spotting that bug, The change should be in cht-core/couchdb here: cht-core/couchdb/docker-entrypoint.sh at master · medic/cht-core · GitHub
@icrc-fdeniger - thanks for your post!
I would recommend checking out both our helm charts and a node script “deploy” that we’ve written. Hopefully they’ll be either directly useful or give you good tips on how you can do it yourself to use CHT CouchDB images.
For sure Medic deployments use helm, use these helm charts and, most importantly, support multi-node couch deployments.
Any progress toward making partners more easily able to deploy using helm (using CHT images) is most welcome!
