Re: Tracking/logging bruteforcing, especially on admin accounts?

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

Re: Organizing the built-in system check framework's hint messages

Here is a super quick proof of concept that I put together. I just branched my fork of django and added a little to it. Here is the comparing changes page[1]. Quick summary of changes: I created a dictionary that would contain the (id: message) pairs. I also modified the CheckMessage.__init__

Re: need not_equal and not_in query lookup types for a natural use case that can't easily be implemented with existing queries

BTW, if I understand your problem correctly you might be able to do this using a subquery: non_special_items = Item.objects.exclude(id__in=special_items) special_only_bundles = Bundle.objects.exclude(items__in=non_special_items) On Thursday, May 19, 2016 at 11:19:42 PM UTC+10, David Xiao

Re: Unicode normalization for username field

Hi David, I agree with your reasoning but I think you're missing an important detail about unicode username support: they have been mistakenly enabled on Python 3 since Django added support for it (1.5-1.6). If we were to disallow non-ASCII characters silently from Django 1.10 Python 3

Re: Unicode normalization for username field

> > - I'm afraid this change may result in boilerplate as most custom user > models will revert to Django's historical (and in my opinion sensible) > username validation rules. > That's a tough question to estimate. This might be true for most English monolingual web sites, but not

Re: Organizing the built-in system check framework's hint messages

The security checks errors are defined as module level constants to avoid some redundancy since these can be imported in tests: https://github.com/django/django/blob/0eac5535f7afd2295b1db978dffb97d79030807e/django/core/checks/security/base.py. If you feel your approach would be an improvement,

Re: need not_equal and not_in query lookup types for a natural use case that can't easily be implemented with existing queries

> If there is an easy answer, one using a single query, please let me know.) Can you post what your desired SQL would look like? IIRC, foo.exclude(id__in=[bar, baz]) already adds "NOT IN" to the SQL query (but I may be wrong), i.e "SELECT foo WHERE id NOT IN (bar, baz)" So what do you propose

Re: Template Tag `url` returns empty string, does not raise NoReverseMatch

On Thursday, May 19, 2016 at 2:41:43 PM UTC+2, guettli wrote: > > Do you use the following use case provided in the docs? > Yes, the admin makes (or at least made) also use of this. -- You received this message because you are subscribed to the Google Groups "Django developers

need not_equal and not_in query lookup types for a natural use case that can't easily be implemented with existing queries

Hi folks, Django is missing a not_equal lookup type for database queries. I know this has been requested before and that the usual response is to use exclude or ~Q. While that works for a lot of use cases, I have a natural use case that I haven't seen discussed and that seems to escape easy

Template Tag `url` returns empty string, does not raise NoReverseMatch

If you use this syntax, then no NoReverseMatch exception gets raised: {% url 'some-url-name' arg arg2 as the_url %} This is documented here: https://docs.djangoproject.com/en/1.9/ref/templates/builtins/#url > This {% url ... as var %} syntax will not cause an error if the view is > missing. >

Re: Tracking/logging bruteforcing, especially on admin accounts?

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 >

Re: Tracking/logging bruteforcing, especially on admin accounts?

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

Re: Tracking/logging bruteforcing, especially on admin accounts?

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

Re: New CharField attribute to handle CharField(null=True, blank=True, unique=True) in model forms

The design and the patch look good to me. Thanks! Claude Le jeudi 19 mai 2016 05:01:37 UTC+2, Jon Dufresne a écrit : > > Hi, > > Occasionally I'll need to define a CharField on a model that is unique but > also allow blank values. At the database level, this is easily handled by > storing NULL