Cause noone reads docs and this is not really deployment related imo.
What if the checks framework warned it?
--
unai
--
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 st
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
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
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
Finally someone expressed my own feelings about it perfectly :D
On Sun, May 31, 2015 at 08:32:18PM -0500, Joe Tennies wrote:
I actually think this is a great idea. In my mind it parallels Drupal's
"block" idea. (This is actually what I keep hoping DjangoCMS is.)
That stated, it is more of a con
If a project is using an AUTHENTICATION_BACKENDS with only the default
backend in it, and then at some point they need to make some small tweak
(case-insensitive lookups, perhaps), so they subclass it and now have an
AUTHENTICATION_BACKENDS setting that still has only one backend,
basically the sa
We can't default the `backend` argument to anything but a sentinel
value, because if it's supplied, it should take priority, but if it's
not supplied we need to maintain backwards compatibility with existing
behavior, where the `user.backend` annotation is used.
So, to sum app, the behaviour wou
3) Use the only configured backend, if there is only one.
4) Raise ValueError("You have multiple authentication backends
configured; you must provide the `backend` argument to `login`.")
What about defaulting the backend argument to Django's default auth
backend? This way most of the sites wil
Hi Paulo!
If the application has only one backend we always infer it in the login
function. If it isn't, the client needs to provide one explicitly.
Why not pass the single auth backend into the login function? It makes
the design and the documentation much simpler.
--
unai
--
You receive
Hi,
I guess you're right, but that's exactly Markus' point. This is
inconvenient -- it is exactly one of those tradeoffs Aymeric
mentioned, and seems not well balanced to me, as does not look good in
the template code and I don't suppose that every Django developers
knows about {{ block.super }}
Hi!
I see both of your points, but I should also mention that a better
example than what I provided is when you want to have a block inside an
if-statement, which is not possible today:
{% if myvariable %}
{% block myblock %}my content{% endblock %}
{% endif %}
Correct me if I'm wrong but t
Thanks for your great work Preston, I tried to tackle #15053 myself and
I found it was quite a complex issue. I hope I will find some time to
look at it in more detail!
On Sat, Dec 27, 2014 at 09:30:02PM -0800, Preston Timmons wrote:
Hi all,
I've been working on #15053, which enables Django t
Greetings!
I saw that someone suggested "leader" and "follower" - I haven't
thought through whether I find this more palatable.
Well, as an individualist I am, I find those terms quite uninviting too.
Hoping to downplay it a bit, what about BDSM terms "Dominant" and
"Submissive", "Dom" and
13 matches
Mail list logo
