Re: 2020 Authentication Initiativ

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Brachamul
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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Florian Apolloner
Hi Joe,

uff you are bringing up a hard topic :) Yes I absolutely would like Django to have better support for WebAuth (u2f-like tokens at least), and probably another one or two (I'd keep the scope for support in Django small though once we know that the API works).

Getting this actually implemented might be a different story though. I am imaging quite a bit of work and effort. I think a first step would be to spec required features out a bit and then start working on a DEP. Probably raise some money along the way, because I imagine this to be a rather big project -- but the support is certainly there!

Cheers,
Florian

On Friday, April 5, 2019 at 1:17:31 PM UTC+2, Johannes Hoppe wrote:
Hi there,

I wanted to start a longer discussion on authentication. I have been looked a lot into alternative Django authentication backends, to see what ideas people have come up with. Sadly, I also discovered may security issues while reviewing some prominent packages. Anyhow, Django started out with username and password, which for the time being was a good idea I guess. Looking forward, I believe it is a good time to reevaluate that concept for the decade to come.

There have been plenty new developments, 2FA, OAUTH2, SAML, OpenId (connect), OTP and the list goes on. Many of them even made it into proper standards and have been adopted in soft- and hardware.

I think to get the discussion into the right direction, we first need to figure out, what Django is supposed to provide.

IMHO Django should provide a secure and simple (for developers) out of the box solution. That allows anyone who doesn't hold a Phd in crypto science to build a secure web service.
As anything in Django, it should be extendable or swappable for more advanced use cases and there should be plenty well written documentation on how to do that securely.

With that idea in mind, I see a personal problem with password. Passwords have been proven to not be secure, mostly because people are using it wrong. 123456 is still the most commonly used password. So it is not strange to me, that everyone is looking for different authentication methods and developers use different authentication backends. I actually haven't used Django password authentication in the last 5 years and there are other like me, I presume. Out of that demand people even started building their own authentication backends. This is the point where I wished everyone had a Phd in crypto science. Bottom line, you end up with many unsecure services. The very thing Django should be good at, by my definition earlier on.

Anyhow, I am curious what your thoughts on this matter are. Mainly what you believe Django's place in all this is and how this could be implemented.

Best
-Joe

--
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 post to this group, send email to [hidden email].
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/a34ba83c-d52b-4755-b6ea-afc3ac82c5da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Collin Anderson-2
In reply to this post by Brachamul
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):

Also related: UserCreationForm by default allows usernames that differ only by case

On Wed, Apr 10, 2019 at 7:12 AM Barnaby <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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.
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 [hidden email].
To post to this group, send email to [hidden email].
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.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

NOTARO WEB
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 <[hidden email]>:
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):

Also related: UserCreationForm by default allows usernames that differ only by case

On Wed, Apr 10, 2019 at 7:12 AM Barnaby <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com?utm_medium&#61;email&amp;utm_source&#61;footer">https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com.
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com?utm_medium&#61;email&amp;utm_source&#61;footer">https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com.
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 [hidden email].
To post to this group, send email to [hidden email].
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/9c228819-cca1-4011-b047-a81517bc339c%40email.android.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

John D'Ambrosio
In reply to this post by Collin Anderson-2
Email and password is pretty well supported out of the box using the configuration options provided on the AbstractUser (USERNAME_FIELD).  Slightly more complex cases like username and email both being valid login parameters require very thin wrappers.  The greater discussion is about technologies like JWT and OAuth and LDAP, but I feel like those third-party integrations work pretty well and do not bloat all of Django since every team has different needs.

--
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 post to this group, send email to [hidden email].
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/7eaa8bef-25e3-4f08-954a-9dbd4f97f5f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Johannes Hoppe
In reply to this post by NOTARO WEB
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3BceXXdaBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">cmawe...@...>:
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):
<a href="https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion&#39;;return true;">https://groups.google.com/d/topic/django-developers/7feYlp9HqKs/discussion
<a href="https://code.djangoproject.com/ticket/20824" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F20824\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG5FofCcuEG8RAQ7wleCFfKvpJJjw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F20824\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG5FofCcuEG8RAQ7wleCFfKvpJJjw&#39;;return true;">https://code.djangoproject.com/ticket/20824

Also related: UserCreationForm by default allows usernames that differ only by case
<a href="https://code.djangoproject.com/ticket/25617" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25617\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMcYMHueC-BTszOmOKpe2CgPXjg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F25617\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHOMcYMHueC-BTszOmOKpe2CgPXjg&#39;;return true;">https://code.djangoproject.com/ticket/25617

On Wed, Apr 10, 2019 at 7:12 AM Barnaby <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3BceXXdaBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">antoni...@...> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3BceXXdaBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3BceXXdaBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3BceXXdaBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="3BceXXdaBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Dan Davis
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 <[hidden email]> 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 <[hidden email]>:
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):

Also related: UserCreationForm by default allows usernames that differ only by case

On Wed, Apr 10, 2019 at 7:12 AM Barnaby <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
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.
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 [hidden email].
To post to this group, send email to [hidden email].
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.
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 [hidden email].
To post to this group, send email to [hidden email].
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.

--
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 post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Florian Apolloner
In reply to this post by Johannes Hoppe
Hi Joe,

On Thursday, April 11, 2019 at 4:56:05 PM UTC+2, Johannes Hoppe wrote:
@Florian, since I had so many PRs pending review, I had to find other ways to cause chaos ;)

Hehe probably, the autocomplete stuff is on my todo for the sprints (and selenium is mainly waiting for a merge).

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.

Personally I do not think this should be the first thing to do. At least for me the most common way to login is still an identifier + a password in combination with a second factor. And since u2f/totp/webauth do not really need anything from the usermodel aside from a PK for a foreignkey or so, this would be a good starting point. I think that, if needed, cleaning up the user model would be technically easy but hard from a backwards compatibility perspective. Introducing a new authentication flow/pipeline while technically hard would probably be relatively easy to add (new feature and settings while still supporting the old ones for a while).

I will look into it a bit and propose something as a base for discussion.

Yes please, the more written things we have the more we can discuss it and have something concrete getting out of it.

Cheers,
Florian

--
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 post to this group, send email to [hidden email].
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/ed051fa5-e65d-45dc-863e-7f81885b5be8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

René Fleschenberg
In reply to this post by Collin Anderson-2
Hi

> Also related: UserCreationForm by default allows usernames that differ
> only by case
> https://code.djangoproject.com/ticket/25617

I would like to mention CITextField / CIEmailField here. It solves this
problem nicely, in my experience.

However, it is only available on Postgres, and it requires a database
extension that in turn requires superuser access to the database to be
installed.

Do you think it would be realistically possible to have a CITextField
that uses Postgres citext when available and falls back to Python in
other cases?

--
René Fleschenberg

--
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 post to this group, send email to [hidden email].
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/f91b347e-7fc9-f559-c5d4-e2c1124aadfd%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Johannes Hoppe
So I spend a little time fiddling around Django to understand what is possible and where there might be room for API improvements.

I went with the hardest possible way, NO password, NO username. Just one time passwords send via email or SMS. Similar to Django’s password reset function.

I published my work just now, https://django-mail-auth.rtfd.io. I would recommend to have a look at the custom EmailUser that I built. There are a couple of functions and fields that need to be overridden. BUT to my surprise even the management command “createsuperuser” worked.

Anyhow, I am curious to get a little bit of feedback to further investigate the different possibilities and implications this might have for Django’s authentication framework.
On 12. Apr 2019, 18:49 +0200, René Fleschenberg <[hidden email]>, wrote:
Hi

Also related: UserCreationForm by default allows usernames that differ
only by case
https://code.djangoproject.com/ticket/25617

I would like to mention CITextField / CIEmailField here. It solves this
problem nicely, in my experience.

However, it is only available on Postgres, and it requires a database
extension that in turn requires superuser access to the database to be
installed.

Do you think it would be realistically possible to have a CITextField
that uses Postgres citext when available and falls back to Python in
other cases?

--
René Fleschenberg

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/d92P2V0YrbI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/f91b347e-7fc9-f559-c5d4-e2c1124aadfd%40fleschenberg.net.
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 [hidden email].
To post to this group, send email to [hidden email].
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/ccd774f9-db56-4588-97e4-b44370539013%40Spark.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Florian Apolloner
Hi,

On Friday, April 12, 2019 at 8:06:21 PM UTC+2, Johannes Hoppe wrote:
I went with the hardest possible way, NO password, NO username. Just one time passwords send via email or SMS. Similar to Django’s password reset function.

I do not think that is the hardest possible way and as your code shows it is quite easy. I think the goal here should be to allow second factor authentication via webauth etc -- ie anything that is multistep. I am not surprised that email login works easily, it is a single step process after all…

I published my work just now, <a href="https://django-mail-auth.rtfd.io/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdjango-mail-auth.rtfd.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-oFrkP1_6Wv2ChCV0KLCbfauJgw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdjango-mail-auth.rtfd.io%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF-oFrkP1_6Wv2ChCV0KLCbfauJgw&#39;;return true;">https://django-mail-auth.rtfd.io. I would recommend to have a look at the custom <a href="https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcodingjoe%2Fdjango-mail-auth%2Fblob%2F0.1.2%2Fmailauth%2Fcontrib%2Fuser%2Fmodels.py&amp;sa=D&amp;sntz=1&amp;usg=AFQjCNGFXMLGH8DyIlqee-w3_1gFmCp0xQ" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fcodingjoe%2Fdjango-mail-auth%2Fblob%2F0.1.2%2Fmailauth%2Fcontrib%2Fuser%2Fmodels.py\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGFXMLGH8DyIlqee-w3_1gFmCp0xQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fcodingjoe%2Fdjango-mail-auth%2Fblob%2F0.1.2%2Fmailauth%2Fcontrib%2Fuser%2Fmodels.py\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGFXMLGH8DyIlqee-w3_1gFmCp0xQ&#39;;return true;">EmailUser that I built. There are a couple of functions and fields that need to be overridden. BUT to my surprise even the management command “createsuperuser” worked.

You could have reused https://github.com/aaugustin/django-sesame for the signing stuff :)

Cheers,
Florian

--
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 post to this group, send email to [hidden email].
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/27a3e378-09ea-45dd-80e7-f496bcd4ea1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: 2020 Authentication Initiativ

Florian Apolloner


On Saturday, April 13, 2019 at 1:07:39 PM UTC+2, Florian Apolloner wrote:
You could have reused <a href="https://github.com/aaugustin/django-sesame" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Faaugustin%2Fdjango-sesame\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEomkarilPy2qKwbJciLxddHMjqhQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Faaugustin%2Fdjango-sesame\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEomkarilPy2qKwbJciLxddHMjqhQ&#39;;return true;">https://github.com/aaugustin/django-sesame for the signing stuff :)

Ok django-sesame goes into a different direction but might still be worth to look at it.

--
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 post to this group, send email to [hidden email].
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/cc523e73-27f7-4942-acbf-4f2c6fcdee51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.