Cht-core: Users are forced to login one year after they last logged in

[garethbowen]

Describe the bug
Exactly one year after users last logged in if they refresh the page or start the app they are redirected to the login page and cannot return to the app unless they provide valid credentials. This should not occur if the user has been interacting with the app in that time as their session should be renewed every time a request is made to the server.

To Reproduce
Steps to reproduce the behavior:

1. Log in as a CHP. If you check the cookies in the browser you should see the userCtx cookie is set with an expiry exactly 1 year in the future.
2. Modify your local date to be around 10 months in the future
3. Refresh the page
4. The app reloads correctly. Wait a few minutes for the various requests to complete. Expected behavior: the userCtx cookie expiry has been renewed to 1 year from the new date.
5. Modify your local date to be another 6 months in the future
6. Refresh the page
7. You are now redirected to the login page.

Expected behavior
You should not be redirected to the login page because you interacted with the server to keep your session alive in step 4.

Logs
N/A

Screenshots
N/A

Environment

• Instance: gamma.dev
• Browser: Chrome
• Client platform: Linux
• App: webapp and api
• Version: 3.5.0

Additional context
One workaround is to supply the users with their password so they can login again.
Another option is for the administrator to collect the phones back before the end of the year and logout and login again.

[garethbowen]

This regression was introduced in 3.5.0 in this commit when we added the login page to the service worker. This meant we were no longer hitting the login page server side endpoint which used to renew this cookie.

[dianabarsan]

So, pre 3.5, we relied on the user to be redirected to the login page at least once within one year in order for the userCtx cookie to be refreshed?

[garethbowen]

Not necessarily. During that year the CouchDB session expiry would be updated periodically. After a year the userCtx cookie would expire, and the next time the user reloads the page the webapp Session service checks for the cookie, doesn't find it, and boots them to the login page. Then the login page get route sets the userCtx cookie back, which the login page checks for and then redirects them back to the webapp.

[dianabarsan]

Then the login page get route sets the userCtx cookie back

This worked only if the user was online when this happened, right? Otherwise they'd be stuck on the login page.

[garethbowen]

Stuck, until they find an internet connection and reload, yes.

[abbyad]

Is there a way we can automated tests for this to avoid regressions? In the meantime, @medic/quality-assurance can we make sure this is added to release testing?

[brad1905]

Automating time travel tests is a challenge, but I found libfaketime which might help:
https://github.com/wolfcw/libfaketime https://github.com/wolfcw/libfaketime

On Aug 10, 2020, at 8:19 AM, Marc Abbyad [e-mail] wrote:

Is there a way we can automated tests for this to avoid regressions? In the meantime, @medic/quality-assurance https://github.com/orgs/medic/teams/quality-assurance can we make sure this is added to release testing?

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub https://github.com/medic/cht-core/issues/6583#issuecomment-671419082, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO3MZ7WOAER2S72ZGGDAHWTSAAFYVANCNFSM4PZ5MULQ.

[garethbowen]

It's really difficult to automate. I can check for specific things like the userCtx cookie is being refreshed but it won't pick up if some other part of the authentication stack regresses.

@newtewt Can we add a specific manual release test for this until we work out how to automate it?

[dianabarsan]

This is ready for AT on 6583-renew-userCtx-cookie.

The fix for this involves refreshing the expiry time of the userCtx cookie every time a call to /_session is made. One such call is made every time the webapp boots.

[garethbowen]

Diana found a workaround for this issue. Before the cookie expires if you modify the org.couchdb.user:<username> doc for all users in the medic database with a null change (just opening it and saving a new rev should work), then the userCtx cookie expiry will be refreshed for another year. The user will be prompted to refresh but that's not necessary.

[dianabarsan]

Just a quick update to @garethbowen 's comment about the workaround:
The user's roles need to change in order to request a new userCtx: https://github.com/medic/cht-core/blob/3.5.x/webapp/src/js/services/session.js#L74

So adding a new role, that does nothing, should do the trick. (this change needs to happen both in the user doc and in the user-settings doc).

[newtewt]

@dianabarsan I'm still seeing the issue.

I applied the branch.
Log in as offline user.
Make sure the requests settle.
Look at the userCtx expiry date.
Move my time beyond that date.
Sync and move through the app and refresh the page. Eventually I get logged out.

[dianabarsan]

@newtewt

The cookie should be refreshed when you "reload" the app.
So 1st, move your clock to some time before the cookie expires, refresh the app and check the cookie again, it should have an expiry of one year ahead.
We're counting on the user reloading the app at least once within that year :)

[dianabarsan]

The scenario you've described above would be as if, for the whole year, the user would never reload the app.

[newtewt]

Ahh that's my bad. I'm seeing it work as expected now. If the user hits before the expiry they get a refreshed token.

[newtewt]

Added release test for this issue.

https://github.com/medic/medic-release-testing/issues/87

[garethbowen]

Merged.

[dianabarsan]

Just a quick update to @garethbowen 's comment about the workaround:
The user's roles need to change in order to request a new userCtx: https://github.com/medic/cht-core/blob/3.5.x/webapp/src/js/services/session.js#L74

So adding a new role, that does nothing, should do the trick. (this change needs to happen both in the user doc and in the user-settings doc).

Just a quick disclaimer to this using this approach, as it might be important for some projects.

Server-side purging is based on user's roles, so adding a new role (even an unconfigured role) to a user will:
a) make the server redo the purge for the role list from scratch
b) make the user download purge doc ids from 0. The docs will have already been deleted from their device, but the user will need to download all purge ids from the server to get up to date with the new purge database.