Remove django-allauth-2fa, dj-rest-auth and django-user-sessions

[matmair]

This PR remove django-allauth-2fa and replaces it with the inline functions of django-allauth. This reduces the dependency footprint and eliminates a bunch of custom creations.
It also adapts the schema generation process to include all allauth endpoints (they do not use DRF so normal generation is not working).

Update: Most of the planned things we would be interested in are now implemented and the scope shifted a bit - it makes sense to just ripp all auth extensions out and use only allauths built-in things. We have a lot of grown auth-adjacent code that can probably be removed/rewritten.

Related Issues

• Closes Remove django-allauth-2fa #6281
• Closes [UI] Multifactor token configuration #8708
• Closes New Interface - Unable to Login with Google SSO #8949

TODO

• refactor authentication forms && detection of enabled features (see 8912)
• implement custom link target lookup for email from django-allauth
• show user ID in MFA flow
• implement email verification flow
• re-implement registration flow
• re-implement password reset flow
• re-implement password change
• keep auth context somewhere for the local session to refer back to
• move now removed system status info into main status (registration, mfa, sso available)
• switch back to browser flow for auth APIs
• rename all new auth URLs to fix to the current schema
• include schema for auth with central API
• write changelog

Coverage

This relies on several upstream PRs:

• https://codeberg.org/allauth/django-allauth/pulls/4236 (custom frontend URLs)
• https://codeberg.org/allauth/django-allauth/pulls/4235 (allowing email registration even if MFA is enabled)

[netlify]

✅ Deploy Preview for inventree-web-pui-preview canceled.

Name	Link
🔨 Latest commit	a68ac05
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/67b8252d08dc480008e52c4d

[SchrodingersGat]

Some notes:

Login Conflict

If the user is already logged in, attempting a login causes a 409 error. This is throwing a ConflictResponse within allauth as the user is already authenticated. This can cause some very hard to debug behaviour (especially for the typical user) and we should consider how best to handle this.

Ref: pennersr/django-allauth#4008

Registering TOTP Code

When you register a new code (in my case, scan QR into google authenticator) but you enter the incorrect one-time code, there is no feedback / error information supplied. The screenshot below shows this - the API returns an error but there is no UI feedback

Login via TOTP

If you put the wrong code into the login screen there is no error message

---

Note: I have pushed fixes for the missing error messages, not sure how to deal with the "already logged in" state though.

[SchrodingersGat]

Basic Login

Basic login (username / password) continues to work as expected (aside from the 409 error as detailed above).

TOTP Login

After making some small tweaks (see my commits above) I now have TOTP working - seems to function as expected.

• Create new TOTP login
• Test failure case during TOTP creation
• Login via TOTP
• Test failure case during TOTP login
• Remove TOTP from user account
• Normal login after TOTP removed

SSO

...

[matmair]

The 409 error is only a problem if running the frontend separately from the backend (ie with the vite dev server). In the production setup, the logged-in check at the beginning of the flow will catch that.
I will add some error notification.

[matmair]

I think all the mentioned issues should be addressed now, let me know if there is anything else that needs fixing.

[wolflu05]

I'm really sorry, I won't have time currently for any review (that's why I answer so rarely). This is really a huge step for inventree to get rid of more old templating and a modernized login flow. Thank you really much for implementing this.

[SchrodingersGat]

@matmair thanks for adding that error message

I don't have a way of testing SSO for this currently - have you tested this? Against which providers?

[SchrodingersGat]

Regarding the playwright tests, looks like you are hitting some 500 errors:

[matmair]

@SchrodingersGat that is a database-locked error due to us running tests in parallel; this is normally fixed by just retrying a bit

[SchrodingersGat]

@SchrodingersGat that is a database-locked error due to us running tests in parallel; this is normally fixed by just retrying a bit

Would it be worth (as a separate PR) moving to a postgres setup for the playwright testing in CI? We spend a significant amount of time retrying failed tests...

[matmair]

@SchrodingersGat any idea what this segmentation fault is? No idea how I introduced that

[SchrodingersGat]

@matmair working on it here - #9114

(a better fix incoming in #9118)

I think that it was introduced with the new docker image. But it only fails sometimes. I can reproduce locally, under very specific conditions.