I don't think removing the default list from the template is the right
idea. We'd be sacrificing some production users that don't go through
security options on deployment checklists to better support development
environments where the security issue (probably) isn't present. […]
I don't think t
I agree with you that the extra implementation complexity is probably not
right or at least not worth the gain, especially when it comes to things
like testing. I take back what I said about switching behaviour based on
DEBUG. You should also be able to run validators in DEBUG if you choose to.
Possible bug when filter per __month on a variable generated by annotate
p = Person.objects.annotate(
main_date=Case(
When(ok=True, then='date_a'),
default=F('date_b'),
output_field=DateField()
)
)
a = p.filter(main_date__month=9)
print(a)
IndexError at /
tuple
The extra complexity of varying validation logic based on DEBUG doesn't
seem quite right to me, but I guess I won't oppose it if that's the
consensus.
Another option could be this in the generated settings file:
AUTH_PASSWORD_VALIDATORS = [
{
'NAME':
'django.contrib.auth.password_v
I started using django-classy-settings and it works very well for me.
On Sep 7, 2015 8:04 PM, "Josh Smeaton" wrote:
> I don't think removing the default list from the template is the right
> idea. We'd be sacrificing some production users that don't go through
> security options on deployment che
I don't think removing the default list from the template is the right
idea. We'd be sacrificing some production users that don't go through
security options on deployment checklists to better support development
environments where the security issue (probably) isn't present. I do think
we need
I think the simplest solution could be to remove the default list of
AUTH_PASSWORD_VALIDATORS that have been added to the project template
settings file and let the user add it to their own production settings
instead. Do you think this reduces the usefulness of the feature? We could
add a depl
Ok, two things:
1) Markus' idea of having more than one folder for migration modules seems
reasonable enough. I disagree with his comment about the placement of merge
migrations --
> Django needs to know where to
> place the merge-migration. I'd go with the first item in the list
I'd require
+1
On Sep 7, 2015 4:56 PM, "Shai Berger" wrote:
> On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
> > I agree with Aymeric and Markus that createsuperuser should not validate
> > strength of passwords when DEBUG is on. Having to use a secure password
> for
> > development/test accounts is
On Monday 07 September 2015 20:09:06 Marc Tamlyn wrote:
> I agree with Aymeric and Markus that createsuperuser should not validate
> strength of passwords when DEBUG is on. Having to use a secure password for
> development/test accounts is an unnecessary level of interference for
> users.
>
> I ag
Hi everybody,
I would like to volunteer to help maintain Oracle and Oracle GIS backend. I
have been developing (commercial) apps with Django framework and oracle
backend for 8 years now. I am familiar with the problems associated with it
because few times I have been forced to find ways to solv
Hi James,
This proposal makes good sense to me. I think the problem is worth
fixing (I saw this problem on a previous project and never did get to
the bottom of what was causing it!), and you've carefully identified a
backwards-compatible route to fixing it, where no existing code breaks
(further)
Security comes first, so the should stay on by default.
True, security comes first, but from the philosophical point of view, I
wouldn't like forcing by default any particular password policy to the
users. If I understood it right, it isn't just a simple warning that
says your password is too
I agree with Aymeric and Markus that createsuperuser should not validate
strength of passwords when DEBUG is on. Having to use a secure password for
development/test accounts is an unnecessary level of interference for users.
I agree its safer to prevent using admin/admin in production and this is
Ticket: https://code.djangoproject.com/ticket/23832
This is something that's been bugging me for a while, but it's tricky
to get a good compatibility story. Here I'll lay out what's going on
now including obstacles to change, where I think we should be and a
possible route for getting there.
# C
On Monday, September 7, 2015 at 5:37:03 PM UTC+2, Unai Zalakain wrote:
>
> I would even dare to say I'm totally against activated-by-default
> password validators.
Security comes first, so the should stay on by default.
> I think it should be a decision the developers take
> consciously, a
On Mon, Sep 7, 2015 at 3:04 PM, Aymeric Augustin
wrote:
> 2015-09-07 10:00 GMT+02:00 Yann Fouillat :
>> I agree, do you know what tools could I use to emulate 3G ?
>
> As far as I know, the canonical tools are:
>
> - on Linux, netem:
> http://www.linuxfoundation.org/collaborate/workgroups/networki
Hi Wim,
In my opinion, it is very safe and consistent to use password
validation in
all instances and places. It definitely prevents people from using
admin/admin and markus/markus as a login, which sounds safe to me.
If you don't want that, you can change the validators depending on DEBUG in
Hello,
2015-09-07 10:00 GMT+02:00 Yann Fouillat :
> First I will say that most of this pull request is a port of
> https://github.com/django/django/pull/1037 which I ported more or less
> blindly.
>
As far as I can tell, this previous PR was never discussed on
django-developers. Someone threw th
Hello and thanks for the review,
First I will say that most of this pull request is a port
of https://github.com/django/django/pull/1037 which I ported more or less
blindly.
On Sunday, 23 August 2015 19:18:20 UTC+2, Aymeric Augustin wrote:
>
>
> 1) About the general API design
>
> This patch ad
Hello and thanks for the review,
On Monday, 24 August 2015 15:25:11 UTC+2, Tom Christie wrote:
>
> Potential there to treat these as separately reviewable pull requests.
>
> For example - needing streaming template generation doesn't *necessarily*
> imply needing streaming responses. The node-by-
Hi Markus and Aymeric,
In my opinion, it is very safe and consistent to use password validation in
all instances and places. It definitely prevents people from using
admin/admin and markus/markus as a login, which sounds safe to me.
If you don't want that, you can change the validators dependi
22 matches
Mail list logo
