[contrib.auth] Separating tightly coupled User model and auth processes implementations

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[contrib.auth] Separating tightly coupled User model and auth processes implementations

Maciej Gol-2
Hey!

I've been recently working on my small project where I'm trying to keep the domain as separated as possible from Django and other libs/frameworks. Unfortunately, implementing the auth processes using django's machinery turned out to be a bit difficult.

The django auth module depends on the `User.pk` attribute, "silently" supports `User.get_session_auth_hash()` method, uses the model reflection to serialize ids into the session object and forces the usage of AnonymousUser without an easy way out.

It looks like the contrib.auth module does way more than just being a simple glue code that re-uses already existing mechanisms: session backends and auth backends.

I have a proposal of implementation of auth processes in such a way that the old API remains, but it gives Django users way more control over the auth system whilst providing the same security guarantees.
Before going out with my proposal, I would like to know your opinion whether this attempt actually makes sense?

To give you more context:

I have a domain object called `User` which contains id, {first,last}_name, password. And a model `UserModel` which is a subclass of Django's `AbstractUser`. The model is just a mean of persistence for the domain object, handled via `DatabaseRepository`.
My User does not implement the `pk` attribute, nor the `get_session_auth_hash()`. I'm not interested in transforming the `UserModel` model and the `AnonymousUser` django object into my own `User` domain object, either, because that's just taping over leaking implementations.

In the end, I would like to have a way to make sure authenticate/login/logout and other contrib.auth methods use my own auth backend and return the instances of my own domain object.

What do you think?

Best,
Maciej

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7ba4fbb5-d7b5-4a3d-8b33-bec2a3bc761eo%40googlegroups.com.