Some times after close the App the session is closed

[mrsarm]

This happens only some times, and specially if the user force-close the app: instead of returning back to the last URL seeing or to the default URL, the app redirects to the login page.

Discussing this in another issue (#52), this is one theory that may be the reason for the error (#52 (comment)):

this is what I am seeing: medic/cht-core#7343 (comment)

My conclusion is that Android calls a method that persists all cookies (including session cookies) on disk on a schedule (used to be manual in previous versions: https://developer.android.com/reference/android/webkit/CookieSyncManager). If you're quicker and you kill the app before the cookies are saved, you load the "old" cookies when you restart the app.

I think we should investigate if it's possible to reduce the interval at which this method runs, or call the "flush" method ourselves, because it's very easily outperformed by a human.

From the android docs:

The WebView now automatically syncs cookies as necessary. You no longer need to create or use the CookieSyncManager. To manually force a sync you can use the CookieManager method CookieManager#flush which is a synchronous replacement for sync().

[latin-panda]

I noticed something else in slow connections, both phones, same version of both, that I get logged out like this:

1. open the app after 2 days no syncing
2. manually sync
3. a modal pops up with a message saying that my session ended and need to login again, click okay
4. redirected to login page
5. Iogin as offline user but I have internet connection, however it's a bit slow.
6. app is syncing again automatically before it finishes do next step
7. close the app
8. open the app again
9. a modal pops up with a message saying that my session ended and need to login again, click okay
10. redirected to login page.

And I can keep going like this in loop for a while.
I have like 30 docs to replicate.

cc: @garethbowen is this something for v1.1.0 of CHT-Android?

[latin-panda]

Just for tracking, similar case was resolved recently.

[garethbowen]

If the session expiry in couchdb is set to 1 year then this should only happen after 1 year of inactivity, right? If so, it makes sense that this is coming up in development, but it shouldn't happen in production often.

Do you have a fix in mind? Should we explicitly call flush when login is successful for example?

[latin-panda]

If the session expiry in couchdb is set to 1 year then this should only happen after 1 year of inactivity, right? If so, it makes sense that this is coming up in development, but it shouldn't happen in production often.

Just in case, I remember Alex saying that this session setting is configurable , and i-tech-malawi wanted to make it shorter, I sent a question in app-services channel to see if any project has sorter sessions.

Do you have a fix in mind? Should we explicitly call flush when login is successful for example?

No yet sorry, I haven't had the time to debug and brainstorm possible solutions. I'm wondering if this is actually in CHT-Core side instead of CHT-Android 🤔

[latin-panda]

I-tech-malawi -> They are still discussing about shortening the session, evaluating the value for strengthening user account security. They haven't made the change yet.

[latin-panda]

Their biggest use case is:

They have devices shared by multiple users and if this isn't enforced users might not have the discipline to logout after they are done and we end up with everyone sharing that device using the same login

[garethbowen]

Very cool. The session cookie is configurable so that should just work. The thing we'll need to confirm is what happens to the userctx cookie which is currently hardcoded to 1 year. If the second user is offline do we rely on the userctx cookie and just log them in as the first user?

[latin-panda]

If the second user is offline do we rely on the userctx cookie and just log them in as the first user?

Tested in gamma as offline user, no connection. When the session cookie expires, the userctx cookie remains there as expected, the chw can keep using the app normally with that user, and if navigating to login page, then the chw gets redirected to webapp and keep using the app.
When there's connection, regarless of the user type (online | offline) they get redirected to login page and must authenticate to keep using the app