Re: NIST password guidelines [was: vulnerability in password reset]

Hello, Django has had password validation built in as of 1.9. As far as I can see, all guidelines you refer to are already implemented there, and enabled by default in new projects. Could you elaborate on what changes you think we need to make? Erik > On 23 Nov 2016, at 16:21, William

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

Hello, Thank you for raising this, Markus. I am +1 to everything Baptiste said. In particular, if our conclusion of this bug would be that CBV are entirely unsuitable for security sensitive features, I don’t think removing CBV for auth is enough. Because by that logic, our users will be

Re: Password validation in Django revisited

Hi Alex, Carl, On 22 Jun 2015, at 02:43, Carl Meyer wrote: > On 06/21/2015 06:17 PM, Alex Becker wrote: >> With the PR merged, password validation applies to the SetPasswordForm >> and the password changing forms, but not to the UserCreationForm or to >> the creation of

Re: Password validation in Django revisited

compatibility. Erik [1] https://github.com/django/django/pull/4276 <https://github.com/django/django/pull/4276> [2] https://github.com/dropbox/zxcvbn <https://github.com/dropbox/zxcvbn> > On 14 Mar 2015, at 15:26, Erik Romijn <erom...@solidlinks.nl> wrote: > > Hi all, >

Re: Password validation in Django revisited

Would it be > possible to aggregate all of the ValidationErrors? > > Cheers > > > On Monday, 9 March 2015 01:48:00 UTC+11, Erik Romijn wrote: > Hello all, > > I've taken another stab at 16860[1]: having a password validation/policy in > Django. I've made an initial

Re: Password validation in Django revisited

thPasswordValidator so you can create your own > instances and point the setting to it. > > Simon > > Le dimanche 8 mars 2015 10:48:00 UTC-4, Erik Romijn a écrit : > Hello all, > > I've taken another stab at 16860[1]: having a password validation/policy in > Django. I've made

Password validation in Django revisited

Hello all, I've taken another stab at 16860[1]: having a password validation/policy in Django. I've made an initial simple PR[2] to show the approach I'd like to use - no tests or documentation yet, the example validators are not very nice, possibly bad naming, etc. But this should be

Re: CSRF cipher in xor + base64 or Vignere cipher

Hello, In the context of a one time pad on the CSRF token, I don’t see a security advantage to either cipher here. If I read correctly, the argument for Vignere is that it can already produce output suitable for inclusion in form values, not requiring base64 encoding of the one time pad. I’ve

Re: Place on a server

Hello, The best place to get answers to your questions is the django-users email list, > - the web interface is

Re: CSRF REASON_NO_REFERER with meta referrer tags

On 03 Feb 2015, at 16:44, Jon Dufresne wrote: > However some URLs are accessed by a unique URL > containing a nonce without a login. Login is not an option for these > URLs. Sharing this URL is considered very bad and I would like to > avoid it happening unintentionally.

Re: The greatest proposal yet: rename this damn group

I think it would also be a great improvement if we all adopted a standard response for these kind of mails - because no matter what we do, some will still end up here. Almost entirely based on Daniele's previous responses, how about we use: > The best place to get answers to your questions is

Re: integrating django-secure

on. On 01 Sep 2014, at 18:34, Donald Stufft <don...@stufft.io> wrote: > Eh, I think we should advise people to switch on HSTS and with > includeSubdomains if at all possible. > >> On Sep 1, 2014, at 1:31 PM, Erik Romijn <erom...@solidlinks.nl> wrote: >>

Re: integrating django-secure

Hi all, I think finally integrating django-secure is a great step. Making a separate deploy check also makes sense to me. However, I think we should be very cautious with pushing people to enable HSTS. Some of our security headers can cause things to break. For example redirecting to SSL when

Re: on type-specific input fields

oesn't seem to be an issue as browsers which don't > > support that attribute (iOS, Android browsers) don't prevent form > > submission at all so they already have a "" behavior. > > > > Cheers, > > Bruno > > > > On Wed, Jul 23, 2014 a

Re: Requiring GitHub login for actions on Trac

Thank you for working on this, Aymeric. I am definitely +1 on moving to GitHub as sole authentication provider for trac. We could argue about this forever. In the mean time the spam will pile up, core developers will have to spend time deleting all of it, and eventually we'd come to a plan which

Re: Updating the organization of the Django Project

+1 Thanks for all the work on this. Erik -- You received this message because you are subscribed to the Google Groups "Django developers" 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

on type-specific input fields

Hello all, Since Django 1.6, the Django form fields for URLs, numbers and email addresses make use of widgets that use type-specific input fields in their HTML rendering. So instead of rendering them as , they now have type="url", type="number" and type="email". This has upsides: for example,

problem with testing for DeprecationWarning

Hello, I've started working on #22130, the deprecation of fix_ampersands, but I'm running into some trouble with building the tests. I imagine there's someone on this list with more experience in this, who might be able to help. My current patch is at

Accelerated deprecation of fix_ampersands and clean_html

Dear all, I would like to propose the accelerated deprecation of the fix_ampersands built-in template filter, because in all use cases, it either simply does not work, or stimulates the user to create security vulnerabilities. In addition, I would like to deprecate django.utils.html.clean_html.

Django sprint in Amsterdam, The Netherlands, Feb 22/23

Hello all, I’m very happy to announce that a two-day Django sprint will take place on February 22-23 in Amsterdam, Netherlands. This event is organized by the Dutch Django Association. Sign up and more information on: http://www.meetup.com/dutch-django-assocation/events/155766972/ The venue

Re: New to Django - Question: All registered users to post content...

Hello Stephen, On 06 Jan 2014, at 02:48, Retnuh wrote: > I am new to Django (converted from Drupal) and trying to learn Django first > before I dive into converting my site over from HTML,CSS and JS to use Django > and Python… Your best bet for an answer is the

Re: User created objects

Hello Ideo, On Oct 20, 2013, at 9:11 AM, Ideo Rex wrote: > I'm relatively new to Django. So I have a working (local) web application. I > can create new model objects from the admin site, but I would like my users > to be able to create their own objects and save them to the

Re: deprecating ipaddressfield

Hi Michael, On Aug 25, 2013, at 6:27 PM, Michael Manfre wrote: > The code on master doesn't agree with your statement about mysql and sqlite. > sqlite - > https://github.com/django/django/blob/master/django/db/backends/sqlite3/creation.py#L26 SQLite doesn't actually have a

Re: deprecating ipaddressfield

Hi Michael, On Aug 25, 2013, at 12:07 AM, Michael Manfre wrote: > IPAddressField is meant for IPv4 addresses and GenericIPAddressField is for > both IPv4 and IPv6. Most backends define different database data types for > each of those fields. E.g. mysql is char(15) vs

Re: deprecating ipaddressfield

Hello all, On May 18, 2013, at 2:07 PM, Erik Romijn <e...@erik.io> wrote: > As far as I know, IPAddressField has no current features that are not also > available in a GenericIPAddressField. Therefore, I suggest that we, some time > from now, deprecate IPAddressF

maintaining of new localflavor packages

Hello all, With the separation of django-localflavor-* from Django core, one of the discussed advantages is that each localflavor package can have its own maintainer(s). Have we established a process for signing up for this? I couldn't find anything in docs or discussions. The reason I ask,

deprecating ipaddressfield (at some time)

Hello all, Since Django 1.4, we've added GenericIPAddressField, next to IPAddressField. The new GenericIPAddressField supports IPv4 as well as IPv6 addresses, and does normalisation of IPv6 addresses. It can also be configured to only accept IPv4 or IPv6 addresses. As far as I know,

Re: Good practices for production settings

Hi Aymeric, On Mar 17, 2013, at 6:33 PM, Aymeric Augustin wrote: > Daniel Quinn worked on a list of good practices for production settings at the > Utrecht sprint. I completed the patch and I'd like to commit the result: I like the patch overall. I have two

Re: Moving database backends out of the core

Hi all, It seems to me we are mixing a few different discussions here: 1. Should Django core have as few database backends as possible? 1a. If yes, which ones should stay in Django core? 2. What should we do, if anything, with the current situation where it seems difficult to guarantee the

Re: ModelForms and the Rails input handling vulnerability

Hello Luke and others, On Jun 13, 2012, at 1:16 AM, Luke Plant wrote: > On django-core we've been discussing an issue that was security related. > However, we decided it wasn't urgent enough to warrant a security > release, and so we're moving the discussion here (especially because we > couldn't

Re: discrepancy in default CSRF settings

Hi, On Apr 9, 2012, at 11:32 AM, mjl Martin J. Laubach wrote: > In the corresponding view functions, ensure that the > 'django.core.context_processors.csrf' context processor is being used. > Usually, this can be done in one of two ways: > • Use RequestContext, which always uses >

discrepancy in default CSRF settings

Hi, In order to enable CSRF protection, one needs to add the CsrfViewMiddleware to the middleware classes, and add the CSRF context processor to the context processors. However, it seems that the defaults are to add the middleware, but not the context processor. Is there a specific reason for

Re: ipv6 support for runserver - stuck in DDN for 2 yrs

Hi, Ramiro Morales wrote: > On Fri, May 28, 2010 at 7:25 AM, Erik Romijn <erom...@ripe.net> wrote: >> >> I noticed that there is a patch for IPv6 support in runserver, >> http://code.djangoproject.com/ticket/7735 , and a maintainer willing to >> make it

ipv6 support for runserver - stuck in DDN for 2 yrs

Hi, I noticed that there is a patch for IPv6 support in runserver, http://code.djangoproject.com/ticket/7735 , and a maintainer willing to make it cleanly apply to the latest trunk. However, for some reason it's been stuck in DDN for two years. Why is this? It looks to me like a simple patch for