Re: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000

I am -1 on adding a setting to handle a use-case that can be handled by users with a 6-line file: On Monday 28 November 2016 16:05:39 Shai Berger wrote: > > It seems all you need in the overridden runserver is: > > from (...)runserver import Command as BaseCommand > > class Command(BaseCommand

Re: Methodology for increasing the number of PBKDF2 iterations

Tobias, Thanks for the comprehensive benchmarking and summary of the situation! I agree on all points, but I'd like to add, that we should err on the side of high iterations for the simple fact that most developers would sooner accept the risk of a DoS long before the risk of compromised user a

Re: Time based one time password and django ?

There's also , which is fairly easy to integrate into a Django project. As a long-term user of (but rare contributor to) Django I'd say the ease of using one of a number of third-party solutions points to keeping it out of core. Relatedly, integrating custom a

Re: Time based one time password and django ?

I have a project that implements TOTP and U2F as a third-party package: https://github.com/gavinwahl/django-u2f On Sunday, January 15, 2017 at 3:47:56 AM UTC-7, ludovic coues wrote: > > Hello, > > After reading the recent thread on authentification in django, I > wondered about the chance of ge

Re: Time based one time password and django ?

There is also a ticket: https://code.djangoproject.com/ticket/25612 "django.contrib.auth should include support for 2fa out of the box". On Sunday, January 15, 2017 at 6:22:30 AM UTC-5, Florian Apolloner wrote: > > Hi, > > yes we'd very much like to have 2fa in Django. At the minimum we'd like to

Re: Check if dependencies are up to date

Woops I misunderstood the original idea. YPlan's *pip-lock* isn't for checking if the packages are the latest versions as on PyPI, it just checks the current virtualenv is in sync with the requirements.txt file(s) that define it - e.g. if a developer adds a new dependency, the rest of the team need

Re: Check if dependencies are up to date

On Mon, Jan 16, 2017 at 4:47 AM, Adam Johnson wrote: > We implemented something similar at YPlan but discovered that it wasn't a > good idea as a system check, because if a dependency changes from another > devs work then often Django can't even start and run the system check. > Especially a prob

Re: Check if dependencies are up to date

> > I believe this also can be used by Django itself as there are some cases > where contrib apps override core command functionality (I believe this > happens for staticfiles app overriding runserver) > The signals as proposed can't really be used for the staticfiles override, since that requires

Re: Check if dependencies are up to date

Hello, While I was reading this email I got an idea about generic Django command signals that might be useful for extending command functionality without subclassing the Command class and relying on INSTALLED_APPS order. Something like this: from django.core.management.signals import pre_command,

Re: Check if dependencies are up to date

Hi Mathieu, We implemented something similar at YPlan but discovered that it wasn't a good idea as a system check, because if a dependency changes from another devs work then often Django can't even start and run the system check. Especially a problem when upgrading Django itself! Instead we imple

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

One issue is that as far as I know, only PBKDF2 is officially approved by the NIST for password hashing. Many security standards explicitly or implicitly (e.g. "strong cryptography") defer to the NIST, and even if Ar

Check if dependencies are up to date

Hello everyone, I would propose this new Django feature. Now you can check if your dependencies are up-to-date (e.g with `hypothesis` in attachment picture) (it runs with Python2.7 && Python3.6). It is a good habit to check if dependencies are up-to-date, especially for security reasons. I d

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

Hah, sure, exactly like that! Is it documented? Yes, yes it is. https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#using-argon2-with-django On Monday, 16 January 2017 20:12:23 UTC+11, Florian Apolloner wrote: > > > > On Monday, January 16, 2017 at 3:56:44 AM UTC+1, Josh Smeaton wrote

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

On Sun, Jan 15, 2017 at 1:09 PM, Pkl wrote: > My bad, if people are guaranteed 2 x 24-month cycles before a feature gets > removed, it's already much better. However, the same pattern as previously > appears in docs : "each feature release will continue to have a few > documented backwards incomp

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

On Monday, January 16, 2017 at 3:56:44 AM UTC+1, Josh Smeaton wrote: > > I think adding argon2_cffi to extra_requires could be a good idea, so that > users can pip install Django[argon2_cffi]. > You mean like https://github.com/django/django/blob/master/setup.py#L53 *scnr* -- You received

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

If you've been maintaining several django apps for several versions of Django (ie. stable, oldstable, lts) then it's pretty easy to imagine how useful this can be. The deprecation policy removes the need of a compatibility layer for code that should support only one version of Django, but does not