Redefine nav.models.profiles.Account as a Django AbstractBaseUser
#3332
Conversation
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports
|
Test results 12 files 12 suites 12m 48s ⏱️ Results for commit a1a40cd. ♻️ This comment has been updated with latest results. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3332 +/- ##
==========================================
- Coverage 60.79% 60.76% -0.03%
==========================================
Files 606 606
Lines 43794 43805 +11
Branches 48 48
==========================================
- Hits 26623 26618 -5
- Misses 17159 17175 +16
Partials 12 12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This changes NAV's Account model to inherit from Django's AbstractBaseUser in order to move towards more compatibility with Django libraries for authentication and authorization.
This makes NAV's authentication middleware more or less replace Django's authentication middleware (for now). `request.account` was initially chosen by NAV to stay out of Django's hair - but most Django stuff expects `request.user` to represent the authenticated user.
lunkwill42
force-pushed
the
feature/add-django-user-model
branch
from
d34d15c to
3396595
Compare
|
|
This likely has some relevance to @hmpf's research in #2865 . I suspect NAV went with custom session middleware due to issues with how Switching to a Django-compatible auth model may potentially make it possible/easier to ditch our own custom session code as well. The biggest difference currently seems to be how Django's auth middleware uses a pseudo-user class for anonymous users, while NAV uses an actual anonymous user representation in the database (which is why this PR sticks with the existing custom middleware) |
As per suggestions from code review, it might be a good idea to implement these to ensure some semblance of compatibility with other Django libraries that may expect user objects to come from django.contrib.auth
As suggested in code review, many libraries expect the Django user account to have an email field. The AbstractUser implementation even provides a method to get the name of the field that contains the user's email address. NAV currently has no need for emails attached directly to user objects, so this field is just being added for the sake of compatibility. It may slip into usage at a later stage.
rename migration script due to naming conflict
lunkwill42
force-pushed
the
feature/add-django-user-model
branch
from
f645214 to
289d319
Compare
|
This attempts to achieve some of the initial things laid out by @hmpf in #2688. It's up for discussion and refinement, but seems to pass the test suite and simple manual tests.
Fixed #3339