Platform UI refuses to log out

[LavissaWoW]

Please verify that this bug has NOT been raised before.

• I checked and didn't find a similar issue

Describe the bug*

Discovered when I was setting up Platorm UI for dev, trying to log out simply sends you to the Home page and tells you that you were already logged in

Steps to Reproduce

Not sure about the exact trigger here. It's still occuring to me as it did yesterday.

Expected behaviour

Being able to log out

Deployment Method

• Docker
• Bare metal

Version Information

InvenTree - inventree.org
The Open-Source Inventory Management System

Installation paths:
Base /workspaces/InvenTree
Config /workspaces/InvenTree/dev/config.yaml
Media /workspaces/InvenTree/dev/media
Static /workspaces/InvenTree/dev/static

Versions:
Python 3.10.10
Django 3.2.23
InvenTree 0.13.0 dev
API 152
Node v20.9.0
Yarn 1.22.19

Commit hash:dabd95d
Commit date:2023-11-21

Please verify if you can reproduce this bug on the demo site.

• I can reproduce this bug on the demo site.

Relevant log output

Created new API token for user 'admin' (name='inventree-web-app')
[22/Nov/2023 17:23:56] "GET /api/user/token/?name=inventree-web-app HTTP/1.1" 200 114
[22/Nov/2023 17:23:56] "GET /api/user/me/ HTTP/1.1" 200 134
[22/Nov/2023 17:23:56] "GET /api/notifications/?read=false&limit=1 HTTP/1.1" 200 52
[22/Nov/2023 17:23:57] "GET /api/user/roles/ HTTP/1.1" 200 527
[22/Nov/2023 17:23:57] "GET /api/settings/global/ HTTP/1.1" 200 27344
Created new API token for user 'admin' (name='inventree-web-app')
[22/Nov/2023 17:23:57] "GET /api/user/token/?name=inventree-web-app HTTP/1.1" 200 114
Background worker check failed
Email backend not configured
InvenTree system health checks failed
[22/Nov/2023 17:23:57] "GET /api/ HTTP/1.1" 200 1145
[22/Nov/2023 17:23:57] "GET /api/user/me/ HTTP/1.1" 200 134
[22/Nov/2023 17:23:57] "GET /api/generic/status/ HTTP/1.1" 200 5851
[22/Nov/2023 17:23:57] "GET /api/user/roles/ HTTP/1.1" 200 527
Background worker check failed
Email backend not configured
InvenTree system health checks failed
[22/Nov/2023 17:23:58] "GET /api/settings/global/ HTTP/1.1" 200 27344
[22/Nov/2023 17:23:58] "GET /api/ HTTP/1.1" 200 1145
[22/Nov/2023 17:23:58] "GET /api/settings/user/ HTTP/1.1" 200 13878
[22/Nov/2023 17:23:58] "GET /api/generic/status/ HTTP/1.1" 200 5851
[22/Nov/2023 17:23:58] "GET /api/settings/user/ HTTP/1.1" 200 13878

[LavissaWoW]

Obviously important notes of deployment:
Method: Devcontainer
OS: Windows
Docker running through WSL

[LavissaWoW]

Viewing the user's API token from the classic UI:

No duplicate tokens are listed for the same user

[LavissaWoW]

As a small thought here:
Should perhaps the system invalidate all active tokens after a fresh restart?
Makes sense to purge all active access tokens after a restart. Especially of you're bringing up the system after abuse.

[wolflu05]

That would be really bad for development, as I have to relogin everytime the server code is changed. I would rather add that as a feature to the admin center to revoke all access tokens.

[LavissaWoW]

Fair point. Didn't consider development envs :>

[SchrodingersGat]

Tokens are also used for many headless applications, forcing them to log out and get a new token would be very inconvenient

[matmair]

The problem seems to be the logged-in check; which I would recommend keeping as it helps with co-existence of CUI and PUI without an extra login (although it also seems to be broken sometimes).

Suggested solution: Add a logout endpoint to the backend that
a) logs out the current django sessions (CUI logout)
b) destroys the used token (PUI logout)

[SchrodingersGat]

I will add another point here which needs further investigation. If you are logged into CUI on your browser (session with CSRF token) then there can be instances where PUI login fails because the CUI session tokens are partially sent also. Works ok in a private browser session.

I'll send some.more info when I can properly document the problem