Re: Should contrib.auth include support for 2fa out of the box?

[Florian Apolloner]

Yes, I would like to see that in contrib.auth, which will require rewriting 
the backends and introduce a auth pipeline ala django-social-auth (has/had) 
-- I was planning to get some thoughts about that on DUTH. Also see this 
(short) twitter discussion: 
https://twitter.com/jacobian/status/651527202119397376 -- so the need is 
definitely there. 

Cheers,
Florian

On Monday, October 26, 2015 at 6:22:46 PM UTC+1, Tim Graham wrote:
>
> On Trac [1], Alex says, "Django did a tremendous service to its users by 
> making strong password hashing be the default. The world is pushing 
> forward, and now 2fa is the next standard that many sites fail to meet. 
> Django should include support for 2fa out of the box, ideally with support 
> for both u2f and TOTP (Google Authenticator)."
>
>
> Doing a quick search, I found 
> https://github.com/Bouke/django-two-factor-auth 
> 
>  
> as a possible existing implementation that might be a starting point if we 
> decide to integrate something. What do you think? One sticking point could 
> be that it uses a ThreadLocals middleware. I didn't look to see how 
> "necessary" that is.
>
>
> [1] https://code.djangoproject.com/ticket/25612
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/140a74cc-6bea-40c8-892b-aeb0079669a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should contrib.auth include support for 2fa out of the box?

[Florian Apolloner]

On Tuesday, October 27, 2015 at 12:46:47 AM UTC+1, Joey Wilhelm wrote:
>
> Fwiw, 2fa is on my short list of things to implement into my current 
> project. It's a fairly important feature to me, as this is a financial 
> project. And that particular implementation is precisely what I was looking 
> to use. I would happily contribute money and/or time toward this 
> implementation, especially if there was a happy upgrade path from Bouke's 
> library.
>

I think if Django supports 2fa the changes will go much deeper than what 
django-otp etc currently do, in that sense it is unlikely that there will 
be any supported upgrade path. If you can transfer the current data to the 
new system is hard to say, but probably doable… 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35ab5dd7-e326-4fe3-8b04-d895c8b81ec2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9: default='' no longer permitted on model field (with blank=False)

[charettes]

Hi everyone,

I proceeded to revert the commit for now.

Nothing prevent us from adding a warning in the future if we ever fix the 
whole "blank" issue at the model level.

Simon

Le samedi 24 octobre 2015 12:29:44 UTC-4, Shai Berger a écrit :
>
> Hi, 
>
> On Saturday 24 October 2015 04:13:47 charettes wrote: 
> > Hi everyone I'm the author of this change. 
> >   
> > I submitted a PR (https://github.com/django/django/pull/5471) to 
> completely 
> > revert this change given suggest adjustments don't get enough support. 
> > 
> I don't think that's the right fix. I think a field whose default value 
> fails 
> its "clean" method is bogus and should be flagged. A warning for sure, an 
> error 
> is not insensible. 
>
> However, I'm very surprised to find out that a model field's "clean()" 
> method 
> even looks at the "blank" attribute. Like others on this thread, I was 
> under 
> the impression that it's only for model-form generation. 
>
> Shai. 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d5a29b88-4cb7-4d62-ab73-1fac46c41e2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

improving our Contributor License Agreement process

[Tim Graham]

In 2014 I started to research if we could offer a Google Summer of Code 
project aimed at improving Django's process for collecting and organizing 
CLAs. I didn't complete that proposal when I found some existing solutions, 
in particular https://cla.puppetlabs.com/ which Puppet labs said they were 
planning to open source. Following up on that now, I couldn't find if they 
ever did open source it and the contacts I found for the project (Dawn and 
Jeff) no longer seem to work at the company.

I wonder if anyone has a recommendation for a third-party solution to solve 
this? Our requirements are roughly outlined below.

Overview


The Django software foundation asks all past and future contributors to 
sign a contributor license agreement [1]. Every contributor of non-trivial 
amounts of code (more than just a line or two) to Django is required to 
sign such a document. If somebody is unable to sign the document, their 
contribution (whether it be code, or documentation, or string translations) 
will be removed from Django.

The CLA ensures that the Django Software Foundation (DSF) has clear license 
to all its contributions, which in turns lets us guarantee to users that we 
have no "stray" intellectual property or differently-licensed material.

The DSF current process for collecting CLAs involves downloading a PDF and 
submitting it by mail, fax, or email. This process makes it difficult to 
audit our commit history by mapping commits to CLAs.

Requirements


Contributors must be able to do an online acceptance of terms and 
conditions. We present our license terms, and the user puts in name, email 
address, contact details etc. We validate that the email is valid (by 
having them verify the email address), and we tie it to their Trac and/or 
GitHub handle. This allows us to have tracing for every commit. We also 
have a historical archive of physical documents, which we can use to 
populate the database (obviously not with verified email addresses, but it 
works for legal purposes).

We've also got corporate CLAs which need to be signed by a corporate 
representative, and can cover a bunch of employees (each employee's 
contributions covered from a specific date).

We should add a pull request check that indicates whether or not a 
contributor has signed the CLA.

[1] https://www.djangoproject.com/foundation/cla/

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bbfa7ec9-fd82-4014-adec-519ec3ea8e51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: improving our Contributor License Agreement process

[Riccardo Magliocchetti]

Il 27/10/2015 17:50, Tim Graham ha scritto:

I wonder if anyone has a recommendation for a third-party solution to solve
this? Our requirements are roughly outlined below.


Not a solution but for comparison Libreoffice requests a blanket statement sent 
on a public list then referenced on a wiki page:

https://wiki.documentfoundation.org/Development/Developers


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/562FAD9D.2070505%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Tim Graham]

I created https://code.djangoproject.com/ticket/25617 - Disallow usernames 
that differ only in case in UserCreationForm.

Please voice any concerns on that ticket.

On Monday, October 26, 2015 at 2:24:27 PM UTC-4, Collin Anderson wrote:
>
> I also agree. And to be clear, we're talking about UserCreationForm, 
> right? Or where specifically would we implement this? (What part of Django 
> do you use that doesn't check this?)
>
> On Monday, October 26, 2015 at 2:04:24 PM UTC-4, bliy...@rentlytics.com 
> wrote:
>>
>> > -1 on changing the check of usernames at login to case-insensitive
>> > +1 with preventing the creation of new usernames
>>
>> Ditto
>>
>> On Thursday, October 22, 2015 at 9:33:02 AM UTC-7, mtnpaul wrote:
>>>
>>> Yeah, I was referring to the post by Daniel at the start of the thread, 
>>> not Reid's comment.
>>>
>>> I would be -1 on changing the check of usernames at login to 
>>> case-insensitive. But I would be +1 with preventing the creation of new 
>>> usernames which would match existing usernames in a case-insensitive manner.
>>>
>>> On Wed, Oct 21, 2015 at 3:39 PM, Shai Berger  wrote:
>>>
 Hi,

 On Thursday 22 October 2015 00:01:24 Paul Egges wrote:
 > Perhaps I'm missing something, but this would not change current 
 users,
 > only the creation of new users. It seems that logins would still be 
 case
 > sensitive.

 Not the way Reid presented it:

 > > Le mercredi 21 octobre 2015 15:44:55 UTC-4, Reid Ransom a écrit :
 > >> Is it reasonable to consider changing the default for usernames to 
 be
 > >> case-insensitive in 2.0?

 I think, though, it would be easy enough for us to provide a new, case-
 insensitive base class for users, and change the recommendations in our
 documentation to tell users to inherit that rather than the current
 AbstractBaseUser and AbstractUser. We could also write a simple 
 management
 command to validate lower-case uniquness and turn all usernames to 
 lowercase,
 as preparation for changing the login and registration logic.

 These could all be done outside of core, and perhaps they should be -- 
 the
 only point I see for including them in core is the risk that, as a 
 developer,
 if core doesn't make you think about it from the get-go, by the time you
 decide to make the change you may be stuck with conflicting (lower-case 
 equal)
 usernames in your database. But frankly, I would guess that this 
 problem does
 not really occur very often; that for most sites, if they decide to 
 switch to
 case-insensitive usernames, there would be no problem.

 Regretfully, we can't just switch Django to do that, because of the few 
 sites
 who will have a problem, and no clear upgrade path.

 Shai.

>>>
>>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f58a275-f4a5-471a-8cb5-69db618cc055%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Feature] On CommandError, sys.exit(1)

[bliyanage]

Hm, let me check it out and get back to you.  We had some migrations that 
exited in failure, but with a non-0 exit status during our release.  I'll 
see if I can reproduce this this week.

-Ben

On Monday, October 26, 2015 at 11:21:17 AM UTC-7, Tim Graham wrote:
>
> The place you linked to is ignoring CommandError when parsing arguments. 
> I'm not sure under what conditions this happens (if at all) -- the Django 
> tests don't cover it.
>
> As far as I know, BaseCommand already does sys.exit(1) when there's an 
> unhandled exception: 
> https://github.com/django/django/blob/df0a446fd4c864c003e4f941b5b7abd6f10c9427/django/core/management/base.py#L289-L300
>
> Could you clarify how to reproduce the problem you're seeing?
>
> On Monday, October 26, 2015 at 2:01:17 PM UTC-4, bliy...@rentlytics.com 
> wrote:
>>
>> Is it ok if I do a PR on this?  This seems like it would be really useful 
>> for automation.
>>
>> -Ben
>>
>> On Thursday, October 22, 2015 at 2:20:18 AM UTC-7, Ben Liyanage wrote:
>>>
>>> Hey,
>>>
>>> What do you guys think about this feature request?
>>>
>>> > On CommandError, sys.exit(1)
>>>
>>> It would be pretty easy to do the sys.exit(1) right here: 
>>>
>>>
>>> https://github.com/django/django/blob/df0a446fd4c864c003e4f941b5b7abd6f10c9427/django/core/management/__init__.py#L289
>>>
>>> This would allow you to fail an automated build when migrations (or any 
>>> other management command) failed.  Currently I see no way of doing that.
>>>
>>> Beyond that, I noticed that the sys.exit(1) is not very consistently 
>>> applied on the makemigrations management command (for example, it is not 
>>> called when the --merge parameter is supplied).
>>>
>>> I can do the PR for the CommandError thing (unless anyone sees a reason 
>>> not to, or that would not work/there is a better place to put 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/794a8e8b-2938-4cae-9245-9bdf056ae6ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should contrib.auth include support for 2fa out of the box?

[bliyanage]

+1

This sounds like a great feature, depending on the implementation.

On Monday, October 26, 2015 at 10:22:46 AM UTC-7, Tim Graham wrote:
>
> On Trac [1], Alex says, "Django did a tremendous service to its users by 
> making strong password hashing be the default. The world is pushing 
> forward, and now 2fa is the next standard that many sites fail to meet. 
> Django should include support for 2fa out of the box, ideally with support 
> for both u2f and TOTP (Google Authenticator)."
>
>
> Doing a quick search, I found 
> https://github.com/Bouke/django-two-factor-auth as a possible existing 
> implementation that might be a starting point if we decide to integrate 
> something. What do you think? One sticking point could be that it uses a 
> ThreadLocals middleware. I didn't look to see how "necessary" that is.
>
>
> [1] https://code.djangoproject.com/ticket/25612
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/37f2ad54-c6c0-4e13-a1a3-bd44a1c6adc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3.5 Support in Django 1.8.x?

[Ned Batchelder]

BTW, there's a move afoot to reconsider removing inspect.getargspec: 
http://bugs.python.org/issue20438 and http://bugs.python.org/issue25486


--Ned.

On 10/24/15 10:30 AM, Tim Graham wrote:
Here's the PR to remove 50K lines of deprecation warnings when running 
the Django 1.8 tests on Python 3.5 as well as to fix the two test 
failures caused by those warnings: 
https://github.com/django/django/pull/5472


In case you look and wonder about the build failures, Jenkins broke 
today after a new release of sqlparse. I submitted a fix: 
https://github.com/andialbrecht/sqlparse/pull/203

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f13c34f1-d059-4017-8626-41d6d5c3a760%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/563014A1.7000309%40nedbatchelder.com.
For more options, visit https://groups.google.com/d/optout.

Re: improving our Contributor License Agreement process

[Russell Keith-Magee]

Hi Tim,

On Wed, Oct 28, 2015 at 12:50 AM, Tim Graham  wrote:

> In 2014 I started to research if we could offer a Google Summer of Code
> project aimed at improving Django's process for collecting and organizing
> CLAs. I didn't complete that proposal when I found some existing solutions,
> in particular https://cla.puppetlabs.com/ which Puppet labs said they
> were planning to open source. Following up on that now, I couldn't find if
> they ever did open source it and the contacts I found for the project (Dawn
> and Jeff) no longer seem to work at the company.
>
> I wonder if anyone has a recommendation for a third-party solution to
> solve this? Our requirements are roughly outlined below.
>
> Overview
> 
>
> The Django software foundation asks all past and future contributors to
> sign a contributor license agreement [1]. Every contributor of non-trivial
> amounts of code (more than just a line or two) to Django is required to
> sign such a document. If somebody is unable to sign the document, their
> contribution (whether it be code, or documentation, or string translations)
> will be removed from Django.
>
> The CLA ensures that the Django Software Foundation (DSF) has clear
> license to all its contributions, which in turns lets us guarantee to users
> that we have no "stray" intellectual property or differently-licensed
> material.
>
> The DSF current process for collecting CLAs involves downloading a PDF and
> submitting it by mail, fax, or email. This process makes it difficult to
> audit our commit history by mapping commits to CLAs.
>
> Requirements
> 
>
> Contributors must be able to do an online acceptance of terms and
> conditions. We present our license terms, and the user puts in name, email
> address, contact details etc. We validate that the email is valid (by
> having them verify the email address), and we tie it to their Trac and/or
> GitHub handle. This allows us to have tracing for every commit. We also
> have a historical archive of physical documents, which we can use to
> populate the database (obviously not with verified email addresses, but it
> works for legal purposes).
>
> We've also got corporate CLAs which need to be signed by a corporate
> representative, and can cover a bunch of employees (each employee's
> contributions covered from a specific date).
>
> We should add a pull request check that indicates whether or not a
> contributor has signed the CLA.
>
> [1] https://www.djangoproject.com/foundation/cla/
>
> Thanks for driving this.

One option would be to do the same thing the PSF does - an Adobe eSign form:

https://www.python.org/psf/contrib/contrib-form/

(Or, any other analogous service).

I’m also are of CLAHub:

https://github.com/clahub/clahub

It’s “CLA with github integration as a service” - but the owner has flagged
that they’re in need of assistance. It’s also a Rails codebase (that’s not
a reason to *not* use it -but it’s a reason that we might not be in a
position to offer to take over maintenance).

A final option - but this is one the DSF would need to pursue in
conjunction with legal advice - would be to abandon the idea of CLAs
altogether. There’s a growing body of opinion that they’re not necessary:

http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html

Russ %-)

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq84-gY4s6nFt6Vr6faB_hYLZmrpopQ1xUfFafjztp0_LMaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.