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

[Maciej Gol]

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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7ba4fbb5-d7b5-4a3d-8b33-bec2a3bc761eo%40googlegroups.com.

NUMERIC with unlimited precision not supported (#24920)

[Maciej Gol]

Currently, the DecimalField does not support unlimited precision numeric 
fields that are available in db backends. As in the ticket's description 
and comments https://code.djangoproject.com/ticket/24920 , there were two 
solution proposed: new field, or an update to DecimalField's behavior. I 
wanted to start contributing to Django, and thought that adding this 
feature could be a great way of getting to know Django's code. I was also 
thinking about a way of solving this - perhaps allowing DecimalField's 
max_digits and decimal_places to be None. If so, the field translates to an 
unlimited-precision NUMERIC field. Does it sound like a way to go?

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6ec512c0-9a4d-4af3-a09d-76350a081b90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.