adding object level permissions on the core permissions

[Erick Lestrange mr-programs.com]

I want to add object level permissions to the Django'd core auth app Permission 
model.

currently permission instances follow this string format 
'._' ideally i want this object level permissions to 
follow a similar string format with as few variations from the originals as 
possible

but the main thing this permissions should do is being automatically loaded by 
the template system just as current ones in order to avoid db queries. this is 
a must!

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9651514e-60dc-4bd5-a33e-64b6d36481b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: adding object level permissions on the core permissions

[Jani Tiainen]

Hi.

To achieve object level permissions you need to write custom authentication
backend.

Django does provide support for object level permissions but there isn't
default implementation because object level permissions have different
meaning for different people.

See auth docs for more information.

to 29. maaliskuuta 2018 klo 17.37 Erick Lestrange mr-programs.com <
livingandwast...@gmail.com> kirjoitti:

> I want to add object level permissions to the Django'd core auth app
> Permission model.
>
> currently permission instances follow this string format
> '._' ideally i want this object level permissions to
> follow a similar string format with as few variations from the originals as
> possible
>
> but the main thing this permissions should do is being automatically
> loaded by the template system just as current ones in order to avoid db
> queries. this is a must!
>
> --
> 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 stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9651514e-60dc-4bd5-a33e-64b6d36481b2%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91odL6C2V-v_t4Qjo%2BXTwLztm6PNgLZDF6TGSwRZpELshYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Paul Tiplady]

Closing the loop here -- Tim just 
reopened https://code.djangoproject.com/ticket/470.

This feature would also be useful for achieving zero-downtime migrations, 
as discussed in https://code.djangoproject.com/ticket/29266.

Sounds like the design has mostly been agreed -- would a PR be accepted 
that just implements the simple `db_default` field without attempting 
PostgreSQL RETURNING or database functions (CURRENT_TIMESTAMP), and just 
provides static defaults?

Cheers,
Paul

On Monday, April 4, 2016 at 2:08:39 AM UTC-7, Shai Berger wrote:
>
> Hi everybody, 
>
> Waking this up again because, going over some older stuff, I found a 
> ticket 
> asking for this feature: 
>
> https://code.djangoproject.com/ticket/470 
>
> It was closed wontfix, but if anybody likes to put a 3-digit-numbered 
> Django 
> bug under their belt, it's there. The discussion in this thread would 
> indicate 
> that it should be re-opened. 
>
> Shai. 
>

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0918d753-2d98-4731-8180-922cc8e1d1d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Michael Grijalva]

Yeah seems like `db_default` was the felling, at least last time I scanned 
through this long-going discussion :D 

I've had to tweak Django's migration handling a bit to handle our 
zero-downtime requirements.

SQLalchemy has had this for awhile 
(http://docs.sqlalchemy.org/en/latest/core/defaults.html#server-side-defaults), 
so I see no reason why it can't be done in Django.

On Thursday, March 29, 2018 at 9:12:24 AM UTC-7, Paul Tiplady wrote:
>
> Closing the loop here -- Tim just reopened 
> https://code.djangoproject.com/ticket/470.
>
> This feature would also be useful for achieving zero-downtime migrations, 
> as discussed in https://code.djangoproject.com/ticket/29266.
>
> Sounds like the design has mostly been agreed -- would a PR be accepted 
> that just implements the simple `db_default` field without attempting 
> PostgreSQL RETURNING or database functions (CURRENT_TIMESTAMP), and just 
> provides static defaults?
>
> Cheers,
> Paul
>
> On Monday, April 4, 2016 at 2:08:39 AM UTC-7, Shai Berger wrote:
>>
>> Hi everybody, 
>>
>> Waking this up again because, going over some older stuff, I found a 
>> ticket 
>> asking for this feature: 
>>
>> https://code.djangoproject.com/ticket/470 
>>
>> It was closed wontfix, but if anybody likes to put a 3-digit-numbered 
>> Django 
>> bug under their belt, it's there. The discussion in this thread would 
>> indicate 
>> that it should be re-opened. 
>>
>> Shai. 
>>
>

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/36b8377d-d17e-4ce9-9520-245ad8cca338%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django ORM Handling of Reverse Relationships and Multi-Value Relationships

[Andrew Standley]

I have recently become acquainted with some ORM behaviour for reverse 
relationships that "makes no sense", and I'm hoping someone can explain the 
justification for the current behaviour. 

This specifically relates to `filter` behaviour referenced in 29271 
, and 16554 
 which seems tangentially 
related to several issues with `exclude` (24421 
, 14645 
, 17315 
) and aggregate expressions (
16603 , 19415 
)

Most of the confusion about 'intended' behaviour and confirmed 'bugged' 
behaviour seems to relate to the ORM's use of joins for reverse 
relationships.
I think my personal confusion boils down to two questions.

1) Is there some fundamental limitation in the ORM that prevents reducing 
the number of joins? Several of these tickets indicate how the ORM could 
potentially produce similar results with queries that did not use multiple 
joins. Why is that not desirable behaviour?

2) Why is the current behaviour of `filter` for multi-value relationships 
'intended'? I'm hoping I am missing something obvious but it seems to me 
that `Q` objects would support the type of behaviour suggested in the spanning 
multi-valued relationships 

 documentation 
in a much more inituative manner. In a test case with models

class Related(models.Model):
field = models.CharField(max_length=100)

class Main(models.Model):
field_one = models.CharField(max_length=100)
field_two = models.CharField(max_length=100)
related = models.ForeignKey(Related, on_delete=models.CASCADE)


both

>>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))

SQL:
SELECT "test_app_related"."id", "test_app_related"."field" FROM 
"test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= 
"test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2" OR 
"test_app_main"."field_one" = "1")

and

>>> Related.objects.filter(main__field_two='2').filter(main__field_one='1')

SQL:
SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= "test_app_
main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_related".
"id" = T3."related_id") WHERE ("test_app_main"."field_two" = "two" AND T3.
"field_one" = "one")

Produce exactly the same results but the second seems to have an 
unnecessary extra join, and directly contradicts the behaviour of filter 
with non multi-valued fields.



In short, could someone be kind enough to explain the justification for all 
this weird behaviour with multi-value relationships?


Cheers,
  Andrew

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/22234c13-3152-473f-86bd-04b41efd9203%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

[Ryan Hiebert]

It's a subtle difference between how a single filter works and two filters
work together over to-many relationships. Here's a writeup that I found
helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/

On Thu, Mar 29, 2018 at 4:26 PM, Andrew Standley 
wrote:

> I have recently become acquainted with some ORM behaviour for reverse
> relationships that "makes no sense", and I'm hoping someone can explain the
> justification for the current behaviour.
>
> This specifically relates to `filter` behaviour referenced in 29271
> , and 16554
>  which seems tangentially
> related to several issues with `exclude` (24421
> , 14645
> , 17315
> ) and aggregate expressions (
> 16603 , 19415
> )
>
> Most of the confusion about 'intended' behaviour and confirmed 'bugged'
> behaviour seems to relate to the ORM's use of joins for reverse
> relationships.
> I think my personal confusion boils down to two questions.
>
> 1) Is there some fundamental limitation in the ORM that prevents reducing
> the number of joins? Several of these tickets indicate how the ORM could
> potentially produce similar results with queries that did not use multiple
> joins. Why is that not desirable behaviour?
>
> 2) Why is the current behaviour of `filter` for multi-value relationships
> 'intended'? I'm hoping I am missing something obvious but it seems to me
> that `Q` objects would support the type of behaviour suggested in the spanning
> multi-valued relationships
> 
>  documentation
> in a much more inituative manner. In a test case with models
>
> class Related(models.Model):
> field = models.CharField(max_length=100)
>
> class Main(models.Model):
> field_one = models.CharField(max_length=100)
> field_two = models.CharField(max_length=100)
> related = models.ForeignKey(Related, on_delete=models.CASCADE)
>
>
> both
>
> >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM
> "test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"=
>  "test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2"
>  OR "test_app_main"."field_one" = "1")
>
> and
>
> >>> Related.objects.filter(main__field_two='2').filter(main__field_one='1'
> )
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
> related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= "test_
> app_main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_
> related"."id" = T3."related_id") WHERE ("test_app_main"."field_two" =
> "two" AND T3."field_one" = "one")
>
> Produce exactly the same results but the second seems to have an
> unnecessary extra join, and directly contradicts the behaviour of filter
> with non multi-valued fields.
>
>
>
> In short, could someone be kind enough to explain the justification for
> all this weird behaviour with multi-value relationships?
>
>
> Cheers,
>   Andrew
>
> --
> 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 stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/22234c13-3152-473f-86bd-
> 04b41efd9203%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQBTdZ%3DVSeDa1APVZUTpoT7cFhgRFxxVgY4cVtnS4GYvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

[Curtis Maloney]

On 03/30/2018 08:57 AM, Ryan Hiebert wrote:
It's a subtle difference between how a single filter works and two 
filters work together over to-many relationships. Here's a writeup that 
I found helpful: 
https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/


It's also addressed in the documentation:

https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relationships

--
Curtis

--
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f31f5413-59e8-eec2-7adb-e619bf5637cb%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

[Josh Smeaton]

It sounds like you understand what the current behaviour is, and you think 
that it would be better modelled with Q objects, is that the case? I can 
see where you're coming from, as even the docs explain the difference 
loosely in terms of AND and OR.

Q(entry__headline__contains='Lennon') & Q(entry__pubdate__year=2008) would 
be the filter(cond_a, cond_b).
Q(entry__headline__contains='Lennon') | Q(entry__pubdate__year=2008) would 
be the filter(cond_a).filter(cond_b).

The justification for **not** doing it this way, I suppose, would be that Q 
objects may not have existed at the time, or this was just never 
considered. The justification for not changing it to be this way now would 
be because it'd break user code everywhere.

I agree that the Q &/| logic would be more intuitive, but it's not 
something we can change at this point.

On Friday, 30 March 2018 08:26:44 UTC+11, Andrew Standley wrote:
>
> I have recently become acquainted with some ORM behaviour for reverse 
> relationships that "makes no sense", and I'm hoping someone can explain the 
> justification for the current behaviour. 
>
> This specifically relates to `filter` behaviour referenced in 29271 
> , and 16554 
>  which seems tangentially 
> related to several issues with `exclude` (24421 
> , 14645 
> , 17315 
> ) and aggregate expressions (
> 16603 , 19415 
> )
>
> Most of the confusion about 'intended' behaviour and confirmed 'bugged' 
> behaviour seems to relate to the ORM's use of joins for reverse 
> relationships.
> I think my personal confusion boils down to two questions.
>
> 1) Is there some fundamental limitation in the ORM that prevents reducing 
> the number of joins? Several of these tickets indicate how the ORM could 
> potentially produce similar results with queries that did not use multiple 
> joins. Why is that not desirable behaviour?
>
> 2) Why is the current behaviour of `filter` for multi-value relationships 
> 'intended'? I'm hoping I am missing something obvious but it seems to me 
> that `Q` objects would support the type of behaviour suggested in the 
> spanning 
> multi-valued relationships 
> 
>  documentation 
> in a much more inituative manner. In a test case with models
>
> class Related(models.Model):
> field = models.CharField(max_length=100)
>
> class Main(models.Model):
> field_one = models.CharField(max_length=100)
> field_two = models.CharField(max_length=100)
> related = models.ForeignKey(Related, on_delete=models.CASCADE)
>
>
> both
>
> >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM 
> "test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"=
>  "test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2"
>  OR "test_app_main"."field_one" = "1")
>
> and
>
> >>> Related.objects.filter(main__field_two='2').filter(main__field_one='1'
> )
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
> related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= 
> "test_app_main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_
> related"."id" = T3."related_id") WHERE ("test_app_main"."field_two" = 
> "two" AND T3."field_one" = "one")
>
> Produce exactly the same results but the second seems to have an 
> unnecessary extra join, and directly contradicts the behaviour of filter 
> with non multi-valued fields.
>
>
>
> In short, could someone be kind enough to explain the justification for 
> all this weird behaviour with multi-value relationships?
>
>
> Cheers,
>   Andrew
>

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/81339adc-875e-48ac-a41f-4e45d0c26823%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

[Marten Kenbeek]

These queries are actually not equivalent. Consider the following code:

>>> r = Related.objects.create(field='related')
>>> r.main_set.create(field_one='1', field_two='3')

>>> r.main_set.create(field_one='2', field_two='4')

>>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
]>
>>> Related.objects.filter(main__field_two='2').filter(main__field_one='1')


Here the first queryset matches the Related instance, because it satisfies 
Q(main__field_one='1'), so one of the OR conditions is satisfied. The 
second queryset doesn't match the Related instance because 
.filter(main__field_two='2') is not true. Further filters can only reduce 
the data returned by the queryset. 

The difference between one or two filter calls is more subtle. Consider the 
following queries:

>>> Related.objects.filter(main__field_one='1').filter(main__field_two='4')
]>
>>> Related.objects.filter(main__field_one='1', main__field_two='4')


Here the first query returns the Related instance because it has a related 
Main instance with field_one='1', and it has a (different) related Main 
instance with field_two='4'. Thus it satisfies both conditions, and the AND 
condition is fulfilled. These can be different objects because of the two 
joins, but both conditions still need to be satisfied. The second query 
does not return the Related instance, because it does not have a single 
related Main instance that has both field_one='1' and field_two='4'. In 
this case there's only a single join, so the same Main instance has to 
satisfy both conditions.

On Thursday, March 29, 2018 at 11:26:44 PM UTC+2, Andrew Standley wrote:
>
> I have recently become acquainted with some ORM behaviour for reverse 
> relationships that "makes no sense", and I'm hoping someone can explain the 
> justification for the current behaviour. 
>
> This specifically relates to `filter` behaviour referenced in 29271 
> , and 16554 
>  which seems tangentially 
> related to several issues with `exclude` (24421 
> , 14645 
> , 17315 
> ) and aggregate expressions (
> 16603 , 19415 
> )
>
> Most of the confusion about 'intended' behaviour and confirmed 'bugged' 
> behaviour seems to relate to the ORM's use of joins for reverse 
> relationships.
> I think my personal confusion boils down to two questions.
>
> 1) Is there some fundamental limitation in the ORM that prevents reducing 
> the number of joins? Several of these tickets indicate how the ORM could 
> potentially produce similar results with queries that did not use multiple 
> joins. Why is that not desirable behaviour?
>
> 2) Why is the current behaviour of `filter` for multi-value relationships 
> 'intended'? I'm hoping I am missing something obvious but it seems to me 
> that `Q` objects would support the type of behaviour suggested in the 
> spanning 
> multi-valued relationships 
> 
>  documentation 
> in a much more inituative manner. In a test case with models
>
> class Related(models.Model):
> field = models.CharField(max_length=100)
>
> class Main(models.Model):
> field_one = models.CharField(max_length=100)
> field_two = models.CharField(max_length=100)
> related = models.ForeignKey(Related, on_delete=models.CASCADE)
>
>
> both
>
> >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1'))
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM 
> "test_app_related" INNER JOIN "test_app_main" ON ("test_app_related"."id"=
>  "test_app_main"."related_id") WHERE ("test_app_main"."field_two" = "2"
>  OR "test_app_main"."field_one" = "1")
>
> and
>
> >>> Related.objects.filter(main__field_two='2').filter(main__field_one='1'
> )
>
> SQL:
> SELECT "test_app_related"."id", "test_app_related"."field" FROM "test_app_
> related" INNER JOIN "test_app_main" ON ("test_app_related"."id"= 
> "test_app_main"."related_id") INNER JOIN "test_app_main" T3 ON ("test_app_
> related"."id" = T3."related_id") WHERE ("test_app_main"."field_two" = 
> "two" AND T3."field_one" = "one")
>
> Produce exactly the same results but the second seems to have an 
> unnecessary extra join, and directly contradicts the behaviour of filter 
> with non multi-valued fields.
>
>
>
> In short, could someone be kind enough to explain the justification for 
> all this weird behaviour with multi-value relationships?
>
>
> Cheers,
>   Andrew
>

-- 
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 stop receiving emails from it, send an email 
to django-developer

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

[Andrew Standley]

Thank you all for the replies.

@Josh Smeaton 
Essentially yes; specifically I was wondering whether I was failing to 
consider behaviour that couldn't be modeled via a Q object, since as you 
mention the current 
https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relationships
 documentation 
uses AND vs OR to justify the behaviour.

@Marten Kenbeek
Got it. Thank you sincerely for the example. I feel a bit foolish now it's 
clicked as I realize the documentation says nearly the same thing, but for 
some reason even after reading through the spanning multi-valued 
relationship documentation multiple times I was completely missing the 
point. 

So would I be correct in stating that all the reported weirdness with 
objects appearing multiple times in QuerySets is mostly a side effect of 
implementing the AND condition on *any* related objects?  

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/95015709-2809-4895-97e6-21d02b49f803%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A more useful list of common passwords?

[Brenton Cleeland]

Three years ago Django introduced the CommonPasswordValidator and included 
a list of 1,000 passwords considered to be "common". That list was based on 
leaked passwords and came from xato.net[1].

I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 20,000 of 
which are available in a gist from Royce Williams[3], including the 
frequency, md5 hash and plain text password.

Interestingly there's 27 passwords in the Django list that aren't in the 
HIBP list. I'd post them here but they're mostly short and not safe for 
work.

I've created a ticket for the increase in size[4] but wanted to check in 
and make sure this is something django-developers thinks is valuable.

Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25
[2]: https://haveibeenpwned.com/Passwords
[3]: https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7
[4]: https://code.djangoproject.com/ticket/29274

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A more useful list of common passwords?

[Curtis Maloney]

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That list 
was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 20,000 
of which are available in a gist from Royce Williams[3], including the 
frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in the 
HIBP list. I'd post them here but they're mostly short and not safe for 
work.


I've created a ticket for the increase in size[4] but wanted to check in 
and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25

[2]: https://haveibeenpwned.com/Passwords
[3]: https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7
[4]: https://code.djangoproject.com/ticket/29274

--
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 stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-developers@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5565c4fd-5de3-dc52-c952-5ad4b555bac0%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: A more useful list of common passwords?

[Curtis Maloney]

By which I mean... hi Brenton! Great to see you being active again :)

It's great you've taken the time to do this, and the benefits are very 
clear [improved security], but what are the costs?


Whilst you're at it, what is the new file size?

--
Curtis



On 03/30/2018 04:26 PM, Curtis Maloney wrote:

What sort of performance impact is this having over the existing list?

What's the additional memory load, if any?

--
Curtis


On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
Three years ago Django introduced the CommonPasswordValidator and 
included a list of 1,000 passwords considered to be "common". That 
list was based on leaked passwords and came from xato.net[1].


I'd like to update the list to

a) be from a more reliable / recent source
b) be larger and more in line with the NIST recommendations

Security researcher Troy Hunt has published a massive list of leaked 
passwords, including frequencies on Have I Been Pwned[2]. The top 
20,000 of which are available in a gist from Royce Williams[3], 
including the frequency, md5 hash and plain text password.


Interestingly there's 27 passwords in the Django list that aren't in 
the HIBP list. I'd post them here but they're mostly short and not 
safe for work.


I've created a ticket for the increase in size[4] but wanted to check 
in and make sure this is something django-developers thinks is valuable.


Cheers,
Brenton

[1]: 
https://web.archive.org/web/20150315154609/https://xato.net/passwords/more-top-worst-passwords/#.Wr3H1chxV25 


[2]: https://haveibeenpwned.com/Passwords
[3]: 
https://gist.github.com/roycewilliams/281ce539915a947a23db17137d91aeb7

[4]: https://code.djangoproject.com/ticket/29274

--
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 stop receiving emails from it, send 
an email to django-developers+unsubscr...@googlegroups.com 
.
To post to this group, send email to 
django-developers@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%40googlegroups.com 
. 


For more options, visit https://groups.google.com/d/optout.




--
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2cb005ec-5f22-a77e-ddeb-791ab85ff03c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: A more useful list of common passwords?

[Brenton Cleeland]

Heya, Curtis!

The gzipped file size of the new file is 82K. That's with all 19,999
passwords from Royce's list.

I threw together a quick test that compares the default list to the new
larger one by checking 10,000 random passwords. Speed difference is
negligible, with both varying between 0.8–1.1 seconds on my machine.

Memory usage on the other hand is definitely higher. With the current
Django list of 1,000 passwords memory usage increases by 0.1MiB. With the
new list it's 0.9-1.0MiB. This would be expected, since the list if 20x the
size. To put it into context, the project that I can that test on (a fresh
project using the standard template) was already using 30MiB to run the
management command.

You can see the full output of the memory test here:
https://gist.github.com/sesh/c431b8cc6b5063e31f08b2a4dc3b46f0

I think the trade-off of a little extra memory is worth it. If you *really*
want to save memory you can (should?) disable the common password validator
or provide your own shorter list anyway.

On 30 March 2018 at 16:31, Curtis Maloney  wrote:

> By which I mean... hi Brenton! Great to see you being active again :)
>
> It's great you've taken the time to do this, and the benefits are very
> clear [improved security], but what are the costs?
>
> Whilst you're at it, what is the new file size?
>
> --
> Curtis
>
>
>
>
> On 03/30/2018 04:26 PM, Curtis Maloney wrote:
>
>> What sort of performance impact is this having over the existing list?
>>
>> What's the additional memory load, if any?
>>
>> --
>> Curtis
>>
>>
>> On 03/30/2018 04:24 PM, Brenton Cleeland wrote:
>>
>>> Three years ago Django introduced the CommonPasswordValidator and
>>> included a list of 1,000 passwords considered to be "common". That list was
>>> based on leaked passwords and came from xato.net[1].
>>>
>>> I'd like to update the list to
>>>
>>> a) be from a more reliable / recent source
>>> b) be larger and more in line with the NIST recommendations
>>>
>>> Security researcher Troy Hunt has published a massive list of leaked
>>> passwords, including frequencies on Have I Been Pwned[2]. The top 20,000 of
>>> which are available in a gist from Royce Williams[3], including the
>>> frequency, md5 hash and plain text password.
>>>
>>> Interestingly there's 27 passwords in the Django list that aren't in the
>>> HIBP list. I'd post them here but they're mostly short and not safe for
>>> work.
>>>
>>> I've created a ticket for the increase in size[4] but wanted to check in
>>> and make sure this is something django-developers thinks is valuable.
>>>
>>> Cheers,
>>> Brenton
>>>
>>> [1]: https://web.archive.org/web/20150315154609/https://xato.net/
>>> passwords/more-top-worst-passwords/#.Wr3H1chxV25
>>> [2]: https://haveibeenpwned.com/Passwords
>>> [3]: https://gist.github.com/roycewilliams/281ce539915a947a23db17
>>> 137d91aeb7
>>> [4]: https://code.djangoproject.com/ticket/29274
>>>
>>> --
>>> 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 stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com >> django-developers+unsubscr...@googlegroups.com>.
>>> To post to this group, send email to django-developers@googlegroups.com
>>> .
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/0a215878-9d3f-4446-a018-602694f54904%
>>> 40googlegroups.com >> sgid/django-developers/0a215878-9d3f-4446-a018-602694f54904%
>>> 40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/django-developers/oMWLVK5kTpI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/2cb005ec-5f22-a77e-ddeb-791ab85ff03c%40tinbrain.net.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Brenton

https://brntn.me // @sesh 

-- 
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 stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-develope