Re: Queries about the project idea Improving the Less Popular Backends

[Dingfan Zhao]

Hello, 

Thanks for your reply. I will start contributing patches now. 

Regards,
Dingfan

-- 
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/a4dd1618-8d25-434e-b02a-0021d1255bb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[John D'Ambrosio]

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 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/7eaa8bef-25e3-4f08-954a-9dbd4f97f5f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[NOTARO WEB]

Hello, this my first message... hi for everybodyI 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-serviceAnyway... I would be happy to help.Best regardsJeff NotaroAm 10.04.2019 22:59 schrieb Collin Anderson :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/discussionhttps://code.djangoproject.com/ticket/20824Also related: UserCreationForm by default allows usernames that differ only by casehttps://code.djangoproject.com/ticket/25617On Wed, Apr 10, 2019 at 7:12 AM Barnaby  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-developers+unsubscribe@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/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 django-developers+unsubscribe@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/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 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/9c228819-cca1-4011-b047-a81517bc339c%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[Johannes Hoppe]

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 + 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 > 
> 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 .
> To post to this group, send email to django-d...@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/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 django-d...@googlegroups.com .
> To post to this group, send email to django-d...@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/CAFO84S5ki%3DtuPCZyXf2e_%2Bq%3D7V8Q1a6RX3EJycx51BodwnJZBA%40mail.gmail.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

--

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 
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 + 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  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.
>> To post to this group, send email to django-d...@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/2ec07906-8a2a-4b63-a850-99e8fef95b5a%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this 

Should django.contrib.auth.authenticate check is_active?

[Daniel Tao]

This is essentially an RFC. I've become more familiar with Django's 
authentication backend system lately, and something has stood out to me 
that I'd like to draw attention to.

A new site built with Django is likely to use the default ModelBackend, 
which includes a user_can_authenticate 

 
method that returns False for inactive users (where is_active = False). 
This can create the expectation that inactive users should not be able to 
authenticate as a general rule.

The development team might later choose to introduce some custom 
authentication backends, for example to authenticate with an external 
service or using API tokens, without realizing that these also need to 
check the user's is_active field in order to preserve existing behavior 
(which may have become enshrined in the team's policies, for example if 
they had been setting is_active = False on accounts that had been detected 
performing malicious activity).

In my opinion it would be desirable in a large percentage of cases to move 
the logic in user_can_authenticate out of ModelBackend specifically and 
into the authenticate method itself, so that inactive users are blocked 
from authenticating using *any* backend. This would remove the burden from 
developers of authentication backends to remember to check for is_active in 
each one.

An obvious problem with changing the default behavior is that it would not 
be backwards compatible. How each application interprets is_active is up to 
that application, and some may have authentication backends that allow 
inactive users to authenticate by design. One option for to addressing that 
would be to introduce a setting such as AUTHENTICATION_REQUIRE_ACTIVE, set 
to False by default (but perhaps explicitly set to True for new Django 
projects created with the startproject command), which could be enabled for 
a given application to apply this requirements consistently in a 
future-proof way.

-- 
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/19cbe676-ab7a-4dc9-98ea-d2cfe767695b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should django.contrib.auth.authenticate check is_active?

[Dan Davis]

So, federated login systems such as often handle only user identity
authentication, which is what the AuthBackend does. Sometimes, users can
self-register, and systems such as django-cas-ng (for CAS, not Oauth2).
 Oauth2, although actually granting authorization to the identity
provider's platform (e.g. to a Google user's profile, or even their
email/calendar APIs), are often still used just for the purpose of identity
verification.

You are correct that is_active can become a thing that developers must
think about in designing a system, but because it has to do with
authorization to login and use the Django project/site, I think it is still
a concern of authentication.   Also, while the is*_active* field is part of
the standard user model, it is a 1-line change to disable this check:
https://github.com/django/django/blob/bfe279293c0b9a2b4a463be76f33b2025add20b6/django/contrib/auth/backends.py#L108

Many authentication backends subclass the ModelBackend, but they don't have
to do so and can easily override the user_can_authenticate() method.

Does this answer your question?

On Thu, Apr 11, 2019 at 1:43 PM Daniel Tao  wrote:

> This is essentially an RFC. I've become more familiar with Django's
> authentication backend system lately, and something has stood out to me
> that I'd like to draw attention to.
>
> A new site built with Django is likely to use the default ModelBackend,
> which includes a user_can_authenticate
> 
> method that returns False for inactive users (where is_active = False).
> This can create the expectation that inactive users should not be able to
> authenticate as a general rule.
>
> The development team might later choose to introduce some custom
> authentication backends, for example to authenticate with an external
> service or using API tokens, without realizing that these also need to
> check the user's is_active field in order to preserve existing behavior
> (which may have become enshrined in the team's policies, for example if
> they had been setting is_active = False on accounts that had been detected
> performing malicious activity).
>
> In my opinion it would be desirable in a large percentage of cases to move
> the logic in user_can_authenticate out of ModelBackend specifically and
> into the authenticate method itself, so that inactive users are blocked
> from authenticating using *any* backend. This would remove the burden
> from developers of authentication backends to remember to check for
> is_active in each one.
>
> An obvious problem with changing the default behavior is that it would not
> be backwards compatible. How each application interprets is_active is up to
> that application, and some may have authentication backends that allow
> inactive users to authenticate by design. One option for to addressing that
> would be to introduce a setting such as AUTHENTICATION_REQUIRE_ACTIVE, set
> to False by default (but perhaps explicitly set to True for new Django
> projects created with the startproject command), which could be enabled for
> a given application to apply this requirements consistently in a
> future-proof way.
>
> --
> 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/19cbe676-ab7a-4dc9-98ea-d2cfe767695b%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 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/CAFzonYYO%3DeS2XtAeravOnEXg4CwSBCrvPi7KANBFuR2JTw07NQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A Django Async Roadmap

[Shaggy]

and how it is going ?
is there some interest from django devs?

On Monday, 4 June 2018 15:18:23 UTC+2, Andrew Godwin wrote:
>
> Hello everyone,
>
> For a while now I have been working on potential plans for making Django 
> async-capable, and I finally have a plan I am reasonably happy with and 
> which I think we can actually do.
>
> This proposed roadmap, in its great length, is here:
>
> https://www.aeracode.org/2018/06/04/django-async-roadmap/
>
> I'd like to invite discussion on this potential plan - including:
>
>  - Do we think async is worth going after? Note that this is just async 
> HTTP capability, not WebSockets (that would remain in Channels)
>
>  - Can we do this in a reasonable timeframe? If not, is there a way around 
> that?
>
>  - Are the proposed modifications to how Django runs sensible?
>
>  - How should we fund this?
>
> There's many more potential questions, and I really would love feedback on 
> this. I'm personally pretty convinced that we can and should do this, but 
> this is a decision we cannot take lightly, and I would love to hear what 
> you have to say.
>
> Andrew
>

-- 
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/98e4a315-17a5-4cf9-9ea7-b83234480ec9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.