Hi there, @Florian, since I had so many PRs pending review, I had to find other ways to cause chaos ;)
Besides that I agree, this isn't an easy undertaking and a lot of time will need to be spend on the whiteboard to get this going. Maybe it is worth actually collecting a little bit of money for this. I am sure there are companies that would be willing to invest into a better authentication framework in Django. When it comes to how this could looks like, I see two main pillars: 1. It needs to be extendable. Provide a great framework and let the community rise to the task implement the various systems. 2. There needs to be at least one solid out of the box solution, got get users productive from minute one. With that in mind, I do see something, that would separate the User object from an authentication provider. Both being separate and swappable entities. In a way this is already the case with the user and authentication backend separation. However, the AbstractBaseUser does already implement a password, a natural key and suggest the implementation of a username. All of which are not a given for all authentication mechanisms. I would suggest as a first step to separate the field names from the object methods. Thanks to multi inheritance in Python this should be an easy enough task. I will look into it a bit and propose something as a base for discussion. Best -Joe On Thursday, April 11, 2019 at 1:45:14 PM UTC+2, NOTARO WEB wrote: > > Hello, this my first message... hi for everybody > > I think it could be a micro-service... you would not touch what is there, > which is a huge advantage regarding compatibility. We could start to > monolith django and I think with this Auth history it would be a good > opportunity. Abstraction for django-monolith with base conversation and > then the Auth micro-service... and we open the community can create/improve > other potential micro-service > Anyway... I would be happy to help. > > Best regards > Jeff Notaro > > Am 10.04.2019 22:59 schrieb Collin Anderson <cmawe...@gmail.com > <javascript:>>: > > Email + password auth is definitely a wanted feature out-of the box, and > probably a good first step would be to create a separate AbstractEmailUser > or something like that. Seems to me AbstractUser shouldn't be changed for > backwards compatibility reasons, but maybe something like a > BaseAbstractUser would be helpful? > > And here's a past discussion and ticket (from 5 years ago): > https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion > https://code.djangoproject.com/ticket/20824 > > Also related: UserCreationForm by default allows usernames that differ > only by case > https://code.djangoproject.com/ticket/25617 > > On Wed, Apr 10, 2019 at 7:12 AM Barnaby <antoni...@gmail.com <javascript:>> > wrote: > > If we go to the most common use case, email + password is the current > "default" of the web, rather than username + password. It would make sense > for Django to use email + password by default. > > It also feels like first_name and last_name have no place in AbstractUser > and should me moved to NamedAbstractUser or something. > > So we'd remove username, first_name and last_name by default. > > Regarding other means of authentication, I don't know if Django should > support any out-of-the-box. Magic Links could be a decent default but they > do raise security issues and require email setup. > > -- > 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-d...@googlegroups.com <javascript:>. > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > 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/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > 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-d...@googlegroups.com <javascript:>. > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > 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/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- 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/1bbc83d2-552d-444d-8165-1341b76328c2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
