Focus is the biggest thing - with so many other packages such as python-social-auth and django-cas-ng and django-warrant providing some sort of Federated Login, I don't think it makes sense to try to incorporate social login. However, it would be nice if out of the box could do a register, verify email, login flow, and using email or username as they key would be great.
Backwards compatibility is also important - with django-cas-ng providing authentication for all the django projects where I work, I still needed a back-door to allow AppScan to login as an admin user. So, I make sure users gets a random password, even though we are logging in via CAS anyway. On Thu, Apr 11, 2019 at 10:56 AM Johannes Hoppe <[email protected]> wrote: > 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 <[email protected]>: >> >> 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 <[email protected]> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 > <https://groups.google.com/d/msgid/django-developers/1bbc83d2-552d-444d-8165-1341b76328c2%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 [email protected]. To post to this group, send email to [email protected]. 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/CAFzonYZCsUNs39GxTcLWj5yjQErZ-gR_vSVRZAe3caoAvdgqyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
