Le vendredi 20 mai 2016 02:44:41 UTC+2, Josh Smeaton a écrit :
>
> I understand the reasoning for "use the cache", but not every site has
> caching enabled, especially lots of smaller sites.
>
That's not true. When not specified, the cache backend default to the local
memory cache:
https://docs
I understand the reasoning for "use the cache", but not every site has
caching enabled, especially lots of smaller sites. A separate table could
be used for tracking attempts, and cleared out per user on successful login
attempt/ip address. This table would not need to be huge if designed with
On Thursday, May 19, 2016 at 1:57:50 PM UTC+2, Aymeric Augustin wrote:
>
> Django’s “last_login” field in the user model is a common cause of
> performance issues in large sites. (I believe it’s required to secure
> password resets so we can’t remove it.) Let’s avoid adding more fields with
>
Hello Vaibhav,
> On 19 May 2016, at 08:59, Vaibhav Mallya wrote:
>
> In my view, #2 would be the best starting point - there are going to be a
> relatively small number of admin accounts on the average Django site. Ergo,
> focused brute-forcing or spearfishing seems to be a greater threat than
IP based throttling like django-rest-framework would be ideal! I know there
are some 3rd party libraries that tries to add ip based throttling to
django although not as cool as drf ones.
El jueves, 19 de mayo de 2016, 8:11:27 (UTC-3), Vaibhav Mallya escribió:
>
> Hi everyone,
>
> I've been havin
Hi everyone,
I've been having a great chat with @jacobian here about potential security
improvements to the Django admin UI:
https://gist.github.com/mallyvai/bcb0bb827d6d53212879dff23cf15d03
The admin UI is core to Django's value-prop, and it seems undersecured by
modern standards. I wanted to
