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

Tracking/logging bruteforcing, especially on admin accounts?

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

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 havin

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 to be a greater threat than

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 >

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. >

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 i

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 (Contribution

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 f

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, m

Re: status of 1.10 release blockers

The CSRF patch is merged. I'm a bit stuck on the middleware one, however, I don't think it's a blocker for alpha. I think I'll create the stable branch and make the release later today (in about 7 hours), unless there are objections. On Wednesday, May 18, 2016 at 10:03:17 PM UTC-4, Tim Graham w

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 necessaril

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 develop

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 wrot

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__ m

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: Should we require pytz for timezone support in Django?

Corresponding ticket - #26622 On Tuesday, 17 May 2016 05:51:29 UTC+5:30, Josh Smeaton wrote: > > While writing timezone tests for > https://github.com/django/django/pull/6243 I ran into some issues where > pytz seemed to be required for just about ev

Re: Should we require pytz for timezone support in Django?

Corresponding ticket - #26622 . On Tuesday, 17 May 2016 05:51:29 UTC+5:30, Josh Smeaton wrote: > > While writing timezone tests for > https://github.com/django/django/pull/6243 I ran into some issues where > pytz seemed to be required for just about e

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

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