Logout on browser reload (dsAuthInfo cookie is lost)

[pnbecker]

Describe the bug

When I build DSpace from the current main branch (as of Feb. 6th, 2025: backend: f4bac3781e ; frontend: 8184acc) using the Dockerfiles and docker-compose files from the community, create an account, login via the webui and reload my browser, I'm being logged out.

To Reproduce

Steps to reproduce the behavior:

1. clone the git repositories for backend and frontend.
2. Run docker compose -p foo -f docker/docker-compose.yml build --pull --no-cache in the frontend source directory
3. Run docker compose -p foo -f docker-compose.yml build --pull --no-cache in the backend source directory
4. Start DSpace in the backend source repository: docker compose -p foo -f docker-compose.yml -f dspace/src/main/docker-compose/docker-compose-angular.yml up -d
5. Start a shell in the backend container: docker compose -p foo -f docker-compose.yml -f dspace/src/main/docker-compose/docker-compose-angular.yml exec dspace /bin/bash and call /dspace/bin/dspace create-administrator to create an account
6. open your browser and go to http://localhost:4000
7. login with the freshly created account
8. acknowldege the enduser agreement
9. Hard reload in your browser (ctrl+R or reload button)
10. see that the navbar is gone and the button to open the dropdown to login is shown.

Expected behavior

When I login into dspace and reload in the browser, I should still be logged in.

[pnbecker]

@tdonohue @atarix83 @kshepherd I'm able to reproduce the logout issue with the communities compose and dockerfiles. I use a Mac with Apple Silicon on macOS 14.6.1, Docker Desktop 27.4.0.

[Leano1998]

I was able to reproduce this error by following exactly the instructions @pnbecker gave, but it didn't occur, when I used our production deployment setting (aka pm2... and apache proxy). I'm not sure, if this is the only difference between those scenarios.

I think the logout, is because no authentication cookie is created during login. This is something, I saw, when I compared all cookies created in the two scenarios. Perhaps it helps a bit to identify the problem.

[kshepherd]

One additional note is that as long as you don't reload / redirect the browser, you can use DSpace as the authenticated user OK, so the authentication process itself succeeds and the cookie exists, but something invalidates the session. (most of my own testing is done in dev mode so i'm running the entire application client-side)

[tdonohue]

@pnbecker and @kshepherd : Using the exact steps listed above, I can reproduce this issue, but only on a brand new installation of DSpace.

It looks to me that the issue is that the dsAuthInfo Cookie is created but then lost/blocked. You can see this occur by doing the following:

1. First reproduce the issue to verify that login is lost.
2. Now, open up your browser's DevTools. Find the Cookies that exist for "http://localhost:4000/". In Chrome this is under the "Application" tab -> Storage -> Cookies
3. Verify there is no dsAuthInfo cookie. (This cookie only exists when you are authenticated & it must be there for the User Interface to know you are authenticated.)
4. Now with that DevTools window open, attempt to login again. If you watch closely, the dsAuthInfo Cookie will appear briefly in the list of Cookies but then disappear again (in less than a second).

I've also found a way to stop the issue from happening. It seems like it's related to the "Cookie Settings" in DSpace.

1. Logout
2. Now, click on "Cookie Settings" option in the DSpace footer. You'll see the default Cookie settings window. Click "Save" to save these defaults in your browser.
3. Login again. Try to reproduce the issue. You will no longer be able to.

It seems to be a problem in initializing the Cookie Settings in Orejime (newly added in DSpace 9). So, it's likely related to #3199 (created by @AndreaBarbasso). If your Orejime cookie settings are not initialized, somehow the dsAuthInfo Cookie is being blocked. Once you initialize the Orejime cookie settings, this no longer seems to occur. It's possible that we just need some initial Cookie settings for all new user accounts, or maybe we need to make new users all manually accept the Cookie settings.

It might also have to do with Orejime's default behavior of hiding the Cookie Settings if there's nothing you can change. Maybe this behavior is causing our dsAuthInfo cookie to be blocked until you manually accept the Cookie settings?

I'm not exactly sure where the bug is in our code, but this is the cause of the issue as far as I can see.

I'm flagging this a "needs volunteer". I'm not sure I'll have time to find a fix, but hopefully someone else can. It definitely seems like this bug is specific to pre-9.0, and doesn't impact 8.x or 7.6.x.