BUG: Users are getting logged out of DAWSON unexpectedly

[ttlenard]

Timebox - day to reproduce; day or two to poke around code

Describe the Bug A clear and concise description of what the bug is.

Users are getting logged out of DAWSON unexpectedly. Court users have reported that they continually get logged out of DAWSON multiple times a day.

• Note: Steps to reproduce at least two ways in Edge to cause this have been confirmed below.

Related to https://github.com/flexion/ef-cms/issues/7501?

-One user said she experiences it every 1 hour.
-One user said she experiences it around 5 PM every day -Other users report that it happens to them multiple times a day. -I have also experienced this while testing. -Petitions clerk user reported that this happened twice in one day (10/14/21) after clicking on "create case". Case was saved, but when she opened up the case and was QCing to ensure all the data was entered, she noticed that additional data was entered in the Address line 2 field that she had NOT previously entered.

I have asked if the users typically have multiple DAWSON tabs open, and it varies. Some do, some don't. Not sure if this can be considered the cause?

I also don't think that it has to do with inactivity. Users state that they will be active in the system and continually lose work. Petitions clerk reported that said she once had to re-enter a petition multiple times because the system kept logging her out while entering in a paper petition.

Business Impact/Reason for Severity Medium?

In which environment did you see this bug?

Prod, Test, MIG

Who were you logged in as? Petitions Clerk Docket Clerk Private Practitioner Petitioner ...all the roles I'm guessing...

What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.) Using the application

To Reproduce Steps to reproduce the behavior - suggestion from @codyseibert :

1. Log into DAWSON
2. Close browser
3. Reopen browser, navigate to DAWSON in a manner that doesn't go explicitly to login (bookmark, history URL)
4. Work/stay active in DAWSON for 1 hour and a bit (~65 minutes)
5. Get logged out upon clicking somewhere in the application

Alternatively:

1. Log into DAWSON
2. Perform a function that opens a second tab (clicking the Docket Record link on an Order Search results page works)
3. Close the original tab.
4. Work/stay active in DAWSON for 1 hour and a bit (~65 minutes) in the second tab.
5. Get logged out upon clicking somewhere in the application.

Expected Behavior A clear and concise description of what you expected to happen. I am not logged out while doing work, or inactive for a bit. Is there any specific timeout for inactivity???

Actual Behavior A clear and concise description of what actually happened. Working away in DAWSON, and the system logs me out. I don't necessarily have to be inactive for it to do this for me.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Cause of Bug, If Known

Process for Logging a Bug:

• Complete the above information
• Add a severity tag (Critical, High Severity, Medium Severity or Low Severity). See below for priority definition.

Severity Definition:

• Critical Defect Blocks entire system's or module’s functionality No workarounds available Testing cannot proceed further without bug being fixed.

• High-severity Defect Affects key functionality of an application There's a workaround, but not obvious or easy App behaves in a way that is strongly different from the one stated in the requirements

• Medium-severity Defect A minor function does not behave in a way stated in the requirements. Workaround is available and easy

• Low-severity Defect Mostly related to an application’s UI Doesn't need a workaround, because it doesn't impact functionality

Definition of Done (Updated 4-14-21)

Product Owner

• [x] Bug fix has been validated in the Court's test environment

Engineering

• [ ] Automated test scripts have been written
• [x] Field level and page level validation errors (front-end and server-side) integrated and functioning
• [x] Verify that language for docket record for internal users and external users is identical
• [x] New screens have been added to pa11y scripts
• [x] All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html
• [x] READMEs, other appropriate docs, JSDocs and swagger/APIs fully updated
• [x] UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required)
• [x] Interactors should validate entities before calling persistence methods
• [x] Code refactored for clarity and to remove any known technical debt
• [ ] Deployed to the Court's test environment
• [ ] Handle non-existing cookie in /auth/refresh endpoint

[mmarcotte]

It appears the authentication tokens are only good for one hour. And that about matches the complaints of the user's experiences.

In August, 2020, AWS added the ability to configure value anywhere from 5 minutes to 24 hours.

And I could not find anything in our code that refreshes an an access token. So, eventually after an hour's continuous use, the token simply becomes invalid and the user experiences a "random" logout.

If a user logs out or times out due to inactivity, they will receive a new token when they login.

[mmarcotte]

Well, looks like startRefreshIntervalAction attempts to refresh that token. It appears that's what is likely misfiring...

Wonder if it's due to new tabs being opening and confusing the state for this value.

[mmarcotte]

https://medium.com/@sadnub/simple-and-secure-api-authentication-for-spas-e46bcea592ad

Perhaps make use of HTTP Only cookies since we shouldn't store the refreshToken in local storage or traditional cookies.

[codyseibert]

I'd like to just leave my ideas before I forget.

Due to security reasons, we don't store the refresh token in localstorage. If a user logs in, closes their browser, and reloads their browser, the application will work because it loads the access token from localstorage but that token will NEVER refresh because we don't have the refresh token.

I am pretty sure you can reproduce this issue by simply logging in, close your browser, open it back up, do work for 1+ hour and you'll probably get logged out.

[kkoskelin]

Latest changes performed on branch 8949-tab-logouts and same code currently deployed to exp3. Broadcast Channel strategy works in that new tabs will request (and receive) the refresh token from the first tab. HOWEVER. If you only have one tab open of the application and you hit [reload], you are still authenticated with the application but have thrown away your refreshToken which had been stored in the app state. This means that in 60 minutes you will once again be logged out.

The work on the branch gets us further, but does not solve this last problem of an application reload. Refresh token will have to be stored somewhere accessible to the application post-reload.

[cholly75]

@mmarcotte - let's also make sure we deploy this to IRS Test environment so I can ask them to do a quick regression when ready.