Investigate logout protocol for MyCarePlanner for timeout

[kbertodatti]

It looks like the timeout removes local storage. @drdavec will confirm.

If user just closes the tab, then tokens are still stored and available for the life of the token.

[kbertodatti]

From Dave: testing the current behavior for timeout. I set the timeout to 5 minutes. If I open the app and go off to other work, it does correctly timeout after 5 minutes and I cannot refresh the app to restart, I must relaunch. However, when I relaunch within a hour, the app does remember the Epic Sandbox access token and reloads the same Epic patient without prompting me to login and select the patient. After an hour, this no longer happens. So it appears the access token is saved in user browser state after app timeout.

You can test this in the CarePlanning sandbox by launching the app where the timeout is set to 5 min in this build: https://chronic-care.github.io/mycareplanner/launch.html?iss=https://gw.interop.community/CarePlanning/data

However, you need to also login to Epic sandbox for a realistic test, because the MELD sandbox login is saved in the browser outside of our app and does not prompt re-login to MELD even a few hours later.

[drdavec]

From Dan in Slack:

Session storage and local storage are independent of each other. That's why we went with local storage. We wanted it to outlast a session (originally). That and the types of things we can store are more complex. Anyway, it's easy enough to clear the local storage upon logout. In this case, local forage using indexed DB. I can add that code to the logout if you'd like. At this point, I see no reason not to clear local forage upon logout or time out, given the requirements at the SDS subgroup meeting. It's the path of least resistance/MVP for now. (edited) 8:06 "implications of the access token still being saved in the user browser state" The implications are that if a different patient tries to use the same computer (say a computer in a library, or a family computer with multiple users, or a computer a workplace that is shared)) and the tokens are still valid, they could end up loading someone else's data. If we clear it, we eliminate the issue. Of course, there are more technical approaches to handle it, but, clearing local forage solves multiple issues at once, and takes no logic. We lose the ability to automatically reload data if the token is still valid. But, given that we now have timed sessions and a logout... those use cases are basically irrelevant.

[drbgfc]

Once we add a logout button and have it call handleLogout - localStorage will be fully handled (cleared)