Re: argon2 PasswordHasher

[Bas Westerbaan]

Hi all,

The PR[1] that adds Argon2 as a PasswordHasher is ready to be merged.  It does 
not make Argon2 the default.  The reasons not to make it the default are:

1. Argon2 is young.  (Its design, though, is uncontroversial.)
2. Argon2 requires C-bindings and thus does not work on every platform Django 
wants to support.

I like to discuss how to take away the last concern.

We could make Argon2 the default on a system if the C-bindings are available 
and otherwise fallback to PBKDF2.[2]  The problem is that it might happen that 
switching servers Argon2 might become unavailable and so users might not be 
able to log-in anymore.  To solve this, I wrote a pure Python implementation of 
Argon2.[3]  It it quite a bit slower[4] than the C-version and so I suggest to 
only use it to switch to another PasswordHasher if the C-version of Argon2 
isn’t available anymore.[5]

What do you think?

Best,

  Bas


---
[1] https://github.com/django/django/pull/5876
[2] Maybe add an `should_be_used’ field to the class and skip PasswordHasher’s 
for which this is False.
[3] https://github.com/bwesterb/argon2pure
[4] The Argon2 hash in the PR takes ~5ms in C and ~1.3s in Python.  Having to 
wait 1.3s once per user to change to another PasswordHasher is, I guess, 
acceptable.  (There is still a lot of room for optimisation.  Maybe it could go 
down to ~100ms, but probably not any more.)
[5] Maybe add an `can_be_used’ field to PasswordHasher to indicate that even 
though it should not be used as default, it can still verify.

> On 03 Jan 2016, at 14:52, Bas Westerbaan  wrote:
> 
> Hynek weighted in[1].  I think the PR is ready to merge.
> 
> Best wishes,
> 
>   Bas
> 
> 
> [1] https://github.com/django/django/pull/5876#issuecomment-168411156 
> 
> 
>> On 27 Dec 2015, at 13:39, Florian Apolloner > > wrote:
>> 
>> I do not see anything wrong in the PR and there is probably no reason not to 
>> include it. It would be great if you could get feedback from dstufft and/or 
>> hynek in #cryptography-dev -- not that we miss something.
>> 
>> Cheers,
>> Florian
>> 
>> On Sunday, December 27, 2015 at 12:36:02 AM UTC+1, Bas Westerbaan wrote:
>> Hello,
>> 
>> This morning I submitted a Pull Request[1], which adds a PasswordHasher for 
>> argon2 – the winner of the Password Hashing Competition.[2]  Tim Graham 
>> mentioned I should send an e-mail to this list to discuss it.
>> 
>> The patch is mostly pretty straight-forward.  I would like to add a few 
>> remarks on some of the choices.
>> 
>> 1. There are two Python packages that implement argon2.  Both bind 
>> libargon2[3].  The first is argon2_py[4], which uses ctypes.  The second is 
>> argon2-cffi[5], which uses... cffi.  Bindings using cffi are more portable, 
>> so I choose argon2-cffi.
>> 
>> 2. argon2 has four parameters: (i) variety ("type"), (ii) time cost ("t"), 
>> (iii) memory cost ("m") and (iv) parallelism ("p").  There are two 
>> varieties: argon2i and argon2d.  The first (argon2i) is safest against 
>> side-channel attacks.  The second tries less hard to be secure against 
>> side-channel attacks in favour of being more resilient against GPU 
>> brute-forcing.  For web-apps, the first "argon2i" is the clear choice.  For 
>> the other parameters I choose to use the same defaults as of argon2-cffi: 
>> t=2, m=512, p=2.  On a i7-4790 @ 3.6Ghz the hash takes around 2ms to compute.
>> 
>> Best wishes,
>> 
>>   Bas
>> 
>> 
>> 
>> [1] https://github.com/django/django/pull/5876 
>> 
>> [2] https://password-hashing.net 
>> [3] https://github.com/p-h-c/phc-winner-argon2 
>> 
>> [4] https://github.com/flamewow/argon2_py 
>> 
>> [5] https://github.com/hynek/argon2_cffi 
>> 
>> 
>> -- 
>> 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/topic/django-developers/NTfqP4eNVyA/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/msgid/django-developers/9a3378d2-3a8b-4bd9-b1e0-d64e25475d02%40googlegroups.com
>>  
>> 

[#26151] Refactor MigrationWriter.serialize() to use a factory pattern

[Markus Holtermann]

Hi all,

Ticket: https://code.djangoproject.com/ticket/26151
PR: https://github.com/django/django/pull/6059

This pull request suggests to rewrite the serialization in the 
MigrationWriter to dedicated classes which are then used by a factory 
function. The reasoning behind this is to reduce the complexity of the 
current serialize() function (according to the reporter McCabe Cyclomatic 
Complexity of 50).

The benefit that comes with the new approach -- yet not implemented and 
would be part of a separate issue -- is a dynamic way to introduce new 
serialization options for data types the current MigrationWriter does not 
support. While neither Simon nor Marten nor I could think of any such case, 
we'd like to get other peoples input.

In case we don't come up with cases where the current MigrationWriter 
fails, the discussion should be made if the added overhead is worth it. 
While I find the new code easier to grasp if I'd see it the first time, I'm 
happy to stick to the current implementation.

Cheers,

/Markus

-- 
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/b0626c9e-e21f-48aa-bbf1-4a05a39726f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [#26151] Refactor MigrationWriter.serialize() to use a factory pattern

[Tim Graham]

I doubt that serialization support is "feature complete", given some recent 
history. I guess it would be nice to have the hook so that users don't have 
to wait for the next release of Django.

Django 1.8.1: Added support for serializing datetime.timedelta objects.
Django 1.9: Added support for serialization of functools.partial and 
LazyObject instances.
Django 1.10: Added support for serialization of enum.Enum objects.

On Friday, January 29, 2016 at 8:06:46 AM UTC-5, Markus Holtermann wrote:
>
> Hi all,
>
> Ticket: https://code.djangoproject.com/ticket/26151
> PR: https://github.com/django/django/pull/6059
>
> This pull request suggests to rewrite the serialization in the 
> MigrationWriter to dedicated classes which are then used by a factory 
> function. The reasoning behind this is to reduce the complexity of the 
> current serialize() function (according to the reporter McCabe Cyclomatic 
> Complexity of 50).
>
> The benefit that comes with the new approach -- yet not implemented and 
> would be part of a separate issue -- is a dynamic way to introduce new 
> serialization options for data types the current MigrationWriter does not 
> support. While neither Simon nor Marten nor I could think of any such case, 
> we'd like to get other peoples input.
>
> In case we don't come up with cases where the current MigrationWriter 
> fails, the discussion should be made if the added overhead is worth it. 
> While I find the new code easier to grasp if I'd see it the first time, I'm 
> happy to stick to the current implementation.
>
> Cheers,
>
> /Markus
>

-- 
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/e9ecff22-14d2-4ac4-b809-2a732be53bc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Logged out sessions are resurrected by concurrent requests (ticket 21608)

[Tore Lundqvist]

Hi, everyone!

I confirmed this (21608) non critical security bug a while ago and have 
sense then made a unit test and a fix for it.
I have not gotten any feedback on my PR yet, is there something more I need 
to do to have someone look at this?

Best Regards
Tore Lundqvist

-- 
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/167826b7-90e2-4645-81fa-2b0be1f26c1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: argon2 PasswordHasher

[Marc Tamlyn]

I may not understand the security implications here properly, but as far as
I can tell there isn't a strong enough case that Argon2 is fundamentally
better than PBKDF2 yet? At least no more than people's arguments that
BCrypt is better. I think retaining the simple out of the box experience
where you get good, performant enough password hashing is important. I'd
say 1.3 seconds is fundamentally *not* fast enough. If someone upgrades
their site to Django 1.10 without noticing the change and we force this
upgrade the suddenly every user's login to the site costs 1.3 seconds -
that's an enormous amount of server load.

M

On 29 January 2016 at 10:01, Bas Westerbaan  wrote:

> Hi all,
>
> The PR[1] that adds Argon2 as a PasswordHasher is ready to be merged.  It
> does not make Argon2 the default.  The reasons not to make it the default
> are:
>
> 1. Argon2 is young.  (Its design, though, is uncontroversial.)
> 2. Argon2 requires C-bindings and thus does not work on every platform
> Django wants to support.
>
> I like to discuss how to take away the last concern.
>
> We could make Argon2 the default on a system if the C-bindings are
> available and otherwise fallback to PBKDF2.[2]  The problem is that it
> might happen that switching servers Argon2 might become unavailable and so
> users might not be able to log-in anymore.  To solve this, I wrote a pure
> Python implementation of Argon2.[3]  It it quite a bit slower[4] than the
> C-version and so I suggest to only use it to switch to another
> PasswordHasher if the C-version of Argon2 isn’t available anymore.[5]
>
> What do you think?
>
> Best,
>
>   Bas
>
>
> ---
> [1] https://github.com/django/django/pull/5876
> [2] Maybe add an `should_be_used’ field to the class and skip
> PasswordHasher’s for which this is False.
> [3] https://github.com/bwesterb/argon2pure
> [4] The Argon2 hash in the PR takes ~5ms in C and ~1.3s in Python.  Having
> to wait 1.3s once per user to change to another PasswordHasher is, I guess,
> acceptable.  (There is still a lot of room for optimisation.  Maybe it
> could go down to ~100ms, but probably not any more.)
> [5] Maybe add an `can_be_used’ field to PasswordHasher to indicate that
> even though it should not be used as default, it can still verify.
>
> On 03 Jan 2016, at 14:52, Bas Westerbaan  wrote:
>
> Hynek weighted in[1].  I think the PR is ready to merge.
>
> Best wishes,
>
>   Bas
>
>
> [1] https://github.com/django/django/pull/5876#issuecomment-168411156
>
> On 27 Dec 2015, at 13:39, Florian Apolloner  wrote:
>
> I do not see anything wrong in the PR and there is probably no reason not
> to include it. It would be great if you could get feedback from dstufft
> and/or hynek in #cryptography-dev -- not that we miss something.
>
> Cheers,
> Florian
>
> On Sunday, December 27, 2015 at 12:36:02 AM UTC+1, Bas Westerbaan wrote:
>>
>> Hello,
>>
>> This morning I submitted a Pull Request[1], which adds a PasswordHasher
>> for argon2 – the winner of the Password Hashing Competition.[2]  Tim Graham
>> mentioned I should send an e-mail to this list to discuss it.
>>
>> The patch is mostly pretty straight-forward.  I would like to add a few
>> remarks on some of the choices.
>>
>> 1. There are two Python packages that implement argon2.  Both bind
>> libargon2[3].  The first is argon2_py[4], which uses ctypes.  The second is
>> argon2-cffi[5], which uses... cffi.  Bindings using cffi are more portable,
>> so I choose argon2-cffi.
>>
>> 2. argon2 has four parameters: (i) variety ("type"), (ii) time cost
>> ("t"), (iii) memory cost ("m") and (iv) parallelism ("p").  There are two
>> varieties: argon2i and argon2d.  The first (argon2i) is safest against
>> side-channel attacks.  The second tries less hard to be secure against
>> side-channel attacks in favour of being more resilient against GPU
>> brute-forcing.  For web-apps, the first "argon2i" is the clear choice.  For
>> the other parameters I choose to use the same defaults as of argon2-cffi:
>> t=2, m=512, p=2.  On a i7-4790 @ 3.6Ghz the hash takes around 2ms to
>> compute.
>>
>> Best wishes,
>>
>>   Bas
>>
>>
>>
>> [1] https://github.com/django/django/pull/5876
>> [2] https://password-hashing.net
>> [3] https://github.com/p-h-c/phc-winner-argon2
>> [4] https://github.com/flamewow/argon2_py
>> [5] https://github.com/hynek/argon2_cffi
>>
>
> --
> 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/topic/django-developers/NTfqP4eNVyA/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/msgid/django-developers/9a3378d2-3a8b-4

Re: argon2 PasswordHasher

[Bas Westerbaan]

I may not understand the security implications here properly, but as far as I can tell there isn't a strong enough case that Argon2 is fundamentally better than PBKDF2 yet?Barring any weakness in Blake2 we do not know about, Argon2 is way better than PBKDF2 as it is memory-hard.  The gap between SHA256 and PBKDF2 and PBKDF2 and Argon2 (with Django’s settings) might be of comparable order of magnitude as I outlined in this comment[1].I'd say 1.3 seconds is fundamentally *not* fast enough. If someone upgrades their site to Django 1.10 without noticing the change and we force this upgrade the suddenly every user's login to the site costs 1.3 seconds - that's an enormous amount of server load.That’s not my suggestion.  Sorry I did state it clearly enough.  This 1.3 second login will only happen if the server used to be able to use the fast C-argon2 library, but then can’t use it anymore.  This 1.3 second login will only happen once per user: Django would then switch back to PBKDF2.  A 1.3 second login once per user seems acceptable.  (Off course it’s not acceptable if it would happen every time the user logs in.)Best,  Bas[1] https://github.com/django/django/pull/5876#discussion_r48936346



-- 
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/BCEDC782-875E-474C-8B36-C2D59F430913%40westerbaan.name.
For more options, visit https://groups.google.com/d/optout.

Re: argon2 PasswordHasher

[Marc Tamlyn]

It is once per user, but it's once for *EVERY* user when that scenario
occurs. That could easily bring a site down if sessions were invalidated or
you have short session times. It's far too likely someone will have
serious, hard to debug problems as a result of this magical behaviour.

I also strongly agree with Carl's comment on the PR: Automatic changes in
behaviour based only on the presence or absence of a third-party package
(or C bindings) are questionable in general. We can (and by the sounds of
it should) recommend this hasher strongly, but I don't think we need to
make it the default. Unlike SHA256, PBKDF2 isn't a BAD choice yet, it's
just not the best available.

There's an argument for updating the default project template for new
projects, but that would make setup for new users a lot harder so I don't
really like that idea either.

On 29 January 2016 at 14:56, Bas Westerbaan  wrote:

>
>
> I may not understand the security implications here properly, but as far
> as I can tell there isn't a strong enough case that Argon2 is fundamentally
> better than PBKDF2 yet?
>
>
> Barring any weakness in Blake2 we do not know about, Argon2 is way better
> than PBKDF2 as it is memory-hard.  The gap between SHA256 and PBKDF2 *and* 
> PBKDF2
> and Argon2 (with Django’s settings) might be of comparable order of
> magnitude as I outlined in this comment[1].
>
> I'd say 1.3 seconds is fundamentally *not* fast enough. If someone
> upgrades their site to Django 1.10 without noticing the change and we force
> this upgrade the suddenly every user's login to the site costs 1.3 seconds
> - that's an enormous amount of server load.
>
>
> That’s not my suggestion.  Sorry I did state it clearly enough.  This 1.3
> second login will only happen if the server used to be able to use the fast
> C-argon2 library, but then can’t use it anymore.  This 1.3 second login
> will only happen once per user: Django would then switch back to PBKDF2.  A
> 1.3 second login *once* per user seems acceptable.  (Off course it’s not
> acceptable if it would happen every time the user logs in.)
>
> Best,
>
>   Bas
>
> [1] https://github.com/django/django/pull/5876#discussion_r48936346
>
> --
> 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/BCEDC782-875E-474C-8B36-C2D59F430913%40westerbaan.name
> 
> .
>
> 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/CAMwjO1F1YVspthGnAnCwJDD22-2z2n90aXWCxVxxa9a-pvAFgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: deprecate CommaSeparatedIntegerField?

[Tim Graham]

Thanks for feedback. Created ticket for the deprecation: 
https://code.djangoproject.com/ticket/26154

On Thursday, January 21, 2016 at 3:06:39 AM UTC-5, Shai Berger wrote:
>
> On Thursday 21 January 2016 09:59:49 Aymeric Augustin wrote: 
> > > On 21 janv. 2016, at 07:24, Josh Smeaton  > wrote: 
> > > 
> > > I'm in favour of making the change, just call it out as a backwards 
> > > compatibility. 
> > 
> > If I understand correctly, Oracle users encountering this issue would 
> just 
> > have to adjust the field length? 
> > 
>
> If their field is short enough to begin with. There's a hard limit of 4000 
> bytes; if they need more, they'll need to change from a charfield with 
> Tim's 
> validator to a TextField, and that, in turn, will also force them to 
> change 
> queries with grouping in non-trivial ways. 
>
> 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/2b4630b8-c612-46c5-933f-748d6960abba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: argon2 PasswordHasher

[Bas Westerbaan]

Hi Marc,

To be clear, I think we shouldn't make Argon2 the default just yet.  I
would rather add it as an option for now and make it the default in a
later release.  However, I would like to discuss what would block making
Argon2 the default already.


> It is once per user, but it's once for *EVERY* user when that scenario
> occurs. That could easily bring a site down if sessions were invalidated or
> you have short session times. It's far too likely someone will have
> serious, hard to debug problems as a result of this magical behaviour.

This is indeed a corcern for big websites.

What if we make the sudden absense of a C-argon2 a hard error which
includes instructions to enable the fallback behavior I described?
(To be clear: the absense of C-argon2 would only be an error if it has
actually been used as a password hash --- not if it has never been used.)


> There's an argument for updating the default project template for new
> projects, but that would make setup for new users a lot harder so I don't
> really like that idea either.

How is this different than making Argon2 the default?

Why would the setup be harder?


> I also strongly agree with Carl's comment on the PR: Automatic changes in
> behaviour based only on the presence or absence of a third-party package
> (or C bindings) are questionable in general.

Would bundling argon2-cffi with Django be an option?


> We can (and by the sounds of
> it should) recommend this hasher strongly, but I don't think we need to
> make it the default. Unlike SHA256, PBKDF2 isn't a BAD choice yet, it's
> just not the best available.

I agree, PBKDF2 is not a bad choice if there is a proper password policy in
place.  I also do not want to suggest there is an immediate problem.
Maybe it is helpful to look at a real-world example.  On this site[1]
two huge sets (the "GMail" and the "10 million" set) are analyzed.  The
average entropy of these passords appears to be 21.6 bits.  At the
moment, Django's PBKDF2 uses 60,000 iterations of SHA256.  The ASIC
"AntMiner S7" computes 4000 million SHA-256 per Joule.  Thus a similar
ASIC for PBKDF2 would be able to compute ~2^37 PBKDF2's per kWh.  Thus,
breaking a single 37 bit PBKDF2 would set you back $0.12 (if you have
already such an ASIC).

Ok, not every attacker has the budget to develop ASICs.  Suppose our
average Joe attacker has just a GPU.  According to [2] a cheap AMD7750
gives you 2.66 million SHA-256 per Joule.  That ~2^27 PBKDF2s for $0.12.
Our average 21.6 bit password is cheap to break using PBKDF2.

On my i7-4790 Django's PBKDF2 takes 75ms.  If we pick parameters for
Argon2 such that it also takes 75ms to compute, it will compute
0.3 argon2 per Joule.  That ~2^20 Argon2 for $0.12.  (To be fair,
probably some Atom will be more efficient for this than an i7.)

So even Argon2 won't prevent the average password to be cheaply cracked.
If you follow XKCD's advice and use a "correct horse battery staple"
password of 44 bits, then cracking it will cost (as above)

  if hashed with PBKDF2 and cracked with that ASIC$15.36
  if hashed with PBKDF2 and cracked with that GPU  $15728
  if hashed with Argon2 and cracked with my i7   $2013265

(Even though Argon2 is designed to be hard to compute for ASICs, they
might still do a better job than a general purpose CPU: the difference
above might be smaller.)

Best,

  Bas


[1] http://wpengine.com/unmasked/
[2] https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison

-- 
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/20160129173007.GB23905%40vinnana.westerbaan.name.
For more options, visit https://groups.google.com/d/optout.

Replacing the contrib.sites Site model with a setting?

[Tim Graham]

In another thread about adding a "scheme" field to the Site model [1], I 
floated the idea of moving the data stored by the Site model into a setting:

I've sometimes thought that the Site model violates the principle that you 
shouldn't put configuration in your database. I guess there's some 
usefulness to having a ForeignKey to the site, but... would it be feasible 
to offer a SITES setting that could be used instead? e.g.

SITES = {
1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
...
}

Carl said:+1 to this, I've long felt that the Site model was an 
anti-pattern. I don't know if it's worth deprecating and switching to a 
different system, though; it'd be a relatively painful deprecation for 
those using  it, I would guess.

James said:  "In using Marten Kenbeek's URL dispatch rewrite branch, I've 
found that using the pattern of defining some site configuration in your 
settings is the way to go: it more easily allows you to have URL patterns 
on multiple domain/scheme combinations. I use a dict similar to what Tim 
has shown, and then use it to initialize my scheme/domain URL constraints 
in my root urls.py."

I'd like to get more feedback and ideas about this. Do you think we'll be 
better off in the long run with a setting as opposed to storing the data in 
the database? Maybe writing a new sites app that uses a setting instead of 
trying to modify the existing models-based one would be a better plan.

I think the hard problem to solve is what to do about the Redirect and 
FlatPage models which have ForeignKey and ManyToManyField relations to the 
Site model.

Perhaps some outcome of this discussion plus considering what features of 
related third-party tools like django-hosts [2] might be useful to 
incorporate in Django itself would be worthy of a project like Google 
Summer of Code.

[1] 
https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion
[2] https://github.com/jazzband/django-hosts

-- 
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/52fee0b1-c08f-4ac5-a01e-34b9baa045ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Chris Foresman]

+1 on setting. That's what I've ended up doing on all of my projects 
anyhowways. 

On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham wrote:
>
> In another thread about adding a "scheme" field to the Site model [1], I 
> floated the idea of moving the data stored by the Site model into a setting:
>
> I've sometimes thought that the Site model violates the principle that you 
> shouldn't put configuration in your database. I guess there's some 
> usefulness to having a ForeignKey to the site, but... would it be feasible 
> to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> Carl said:+1 to this, I've long felt that the Site model was an 
> anti-pattern. I don't know if it's worth deprecating and switching to a 
> different system, though; it'd be a relatively painful deprecation for 
> those using  it, I would guess.
>
> James said:  "In using Marten Kenbeek's URL dispatch rewrite branch, I've 
> found that using the pattern of defining some site configuration in your 
> settings is the way to go: it more easily allows you to have URL patterns 
> on multiple domain/scheme combinations. I use a dict similar to what Tim 
> has shown, and then use it to initialize my scheme/domain URL constraints 
> in my root urls.py."
>
> I'd like to get more feedback and ideas about this. Do you think we'll be 
> better off in the long run with a setting as opposed to storing the data in 
> the database? Maybe writing a new sites app that uses a setting instead of 
> trying to modify the existing models-based one would be a better plan.
>
> I think the hard problem to solve is what to do about the Redirect and 
> FlatPage models which have ForeignKey and ManyToManyField relations to the 
> Site model.
>
> Perhaps some outcome of this discussion plus considering what features of 
> related third-party tools like django-hosts [2] might be useful to 
> incorporate in Django itself would be worthy of a project like Google 
> Summer of Code.
>
> [1] 
> https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion
> [2] https://github.com/jazzband/django-hosts
>

-- 
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/ef25366e-e1b4-4f35-ad6c-c5974fd359e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Aymeric Augustin]

> On 29 janv. 2016, at 21:45, Tim Graham  wrote:
> 
> Do you think we'll be better off in the long run with a setting as opposed to 
> storing the data in the database?

Yes.

-- 
Aymeric.

-- 
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/FB136E5B-3C4D-4699-9E6C-02FDABCAE968%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Query on BooleanField with values other than True and False, bug or intentional?

[Chris Foresman]

I have to agree here; it's pretty sloppy to not enforce an explicit boolean 
value and can lead to subtle bugs. In addition to the one mentioned by 
Maxime, consider the case of a nullable boolean field:

>>> bool(None)
False

Maybe that field has a better converter for possible values and explicitly 
allows `None`, but I think it would be fairly trivial to add a stricter 
check and pretty easy to fix code that's not backwards compatible with 
find/replace.


On Friday, January 22, 2016 at 3:18:45 PM UTC-6, Maxime Lorant wrote:
>
> At least, the behaviour is predictable : it uses `bool(value)`. I believe 
> it is not a bug but more a question about the input definition: should we 
> allow non boolean value? I don't see any problem here accepting a string as 
> a `True` value, it is the job of the user to ensure the value is castable 
> to a boolean.
>
> The same behaviour is found on `IntegerField` for example: 
> `Model.objects.filter(pk="foo")` raises `ValueError: invalid literal for 
> int() with base 10: 'foo'` which implies the ORM tried to cast 'foo' as an 
> integer.
>
> On Friday, January 22, 2016 at 8:51:41 PM UTC+1, Kaveh wrote:
>>
>> Today I discovered I can use strings and numbers to query on 
>> BooleanFields.
>>
>> Let's say we have the following model:
>>
>> class Whatever(models.Model):
>> name = models.CharField(max_length=200)
>> is_active = models.BooleanField()
>>
>> The following queries return all instances which their `is_active` field 
>> is True:
>>
>> Whatever.object.filter(is_active=True)
>> Whatever.object.filter(is_active='some_random_text')
>> Whatever.object.filter(is_active=777)
>>
>> and the followings return the ones which are False:
>>
>> Whatever.object.filter(is_active=False)
>> Whatever.object.filter(is_active='')
>> Whatever.object.filter(is_active=0)
>>
>> Is this behaviour intentional or is it a bug? Should queries on 
>> BooleanFields accept strings and numbers?
>>
>

-- 
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/1a2e5302-806b-4dfd-8f38-34c1b15c964d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Query on BooleanField with values other than True and False, bug or intentional?

[Chris Foresman]

Sorry, sbrandt noted the issue of subtle bugs, not Maxime.


On Friday, January 29, 2016 at 4:37:51 PM UTC-6, Chris Foresman wrote:
>
> I have to agree here; it's pretty sloppy to not enforce an explicit 
> boolean value and can lead to subtle bugs. In addition to the one mentioned 
> by Maxime, consider the case of a nullable boolean field:
>
> >>> bool(None)
> False
>
> Maybe that field has a better converter for possible values and explicitly 
> allows `None`, but I think it would be fairly trivial to add a stricter 
> check and pretty easy to fix code that's not backwards compatible with 
> find/replace.
>
>
> On Friday, January 22, 2016 at 3:18:45 PM UTC-6, Maxime Lorant wrote:
>>
>> At least, the behaviour is predictable : it uses `bool(value)`. I believe 
>> it is not a bug but more a question about the input definition: should we 
>> allow non boolean value? I don't see any problem here accepting a string as 
>> a `True` value, it is the job of the user to ensure the value is castable 
>> to a boolean.
>>
>> The same behaviour is found on `IntegerField` for example: 
>> `Model.objects.filter(pk="foo")` raises `ValueError: invalid literal for 
>> int() with base 10: 'foo'` which implies the ORM tried to cast 'foo' as an 
>> integer.
>>
>> On Friday, January 22, 2016 at 8:51:41 PM UTC+1, Kaveh wrote:
>>>
>>> Today I discovered I can use strings and numbers to query on 
>>> BooleanFields.
>>>
>>> Let's say we have the following model:
>>>
>>> class Whatever(models.Model):
>>> name = models.CharField(max_length=200)
>>> is_active = models.BooleanField()
>>>
>>> The following queries return all instances which their `is_active` field 
>>> is True:
>>>
>>> Whatever.object.filter(is_active=True)
>>> Whatever.object.filter(is_active='some_random_text')
>>> Whatever.object.filter(is_active=777)
>>>
>>> and the followings return the ones which are False:
>>>
>>> Whatever.object.filter(is_active=False)
>>> Whatever.object.filter(is_active='')
>>> Whatever.object.filter(is_active=0)
>>>
>>> Is this behaviour intentional or is it a bug? Should queries on 
>>> BooleanFields accept strings and numbers?
>>>
>>

-- 
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/93361723-c7ed-466c-968b-4c1e7f6d34ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Andrey Antukh]

This is just that I'm doing in django-sites package:
https://github.com/niwinz/django-sites .

+ to have the similar approach in django (sites as settings).

On Fri, Jan 29, 2016 at 10:45 PM, Tim Graham  wrote:

> In another thread about adding a "scheme" field to the Site model [1], I
> floated the idea of moving the data stored by the Site model into a setting:
>
> I've sometimes thought that the Site model violates the principle that you
> shouldn't put configuration in your database. I guess there's some
> usefulness to having a ForeignKey to the site, but... would it be feasible
> to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> Carl said:+1 to this, I've long felt that the Site model was an
> anti-pattern. I don't know if it's worth deprecating and switching to a
> different system, though; it'd be a relatively painful deprecation for
> those using  it, I would guess.
>
> James said:  "In using Marten Kenbeek's URL dispatch rewrite branch, I've
> found that using the pattern of defining some site configuration in your
> settings is the way to go: it more easily allows you to have URL patterns
> on multiple domain/scheme combinations. I use a dict similar to what Tim
> has shown, and then use it to initialize my scheme/domain URL constraints
> in my root urls.py."
>
> I'd like to get more feedback and ideas about this. Do you think we'll be
> better off in the long run with a setting as opposed to storing the data in
> the database? Maybe writing a new sites app that uses a setting instead of
> trying to modify the existing models-based one would be a better plan.
>
> I think the hard problem to solve is what to do about the Redirect and
> FlatPage models which have ForeignKey and ManyToManyField relations to the
> Site model.
>
> Perhaps some outcome of this discussion plus considering what features of
> related third-party tools like django-hosts [2] might be useful to
> incorporate in Django itself would be worthy of a project like Google
> Summer of Code.
>
> [1]
> https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion
> [2] https://github.com/jazzband/django-hosts
>
> --
> 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/52fee0b1-c08f-4ac5-a01e-34b9baa045ec%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.nz
https://github.com/niwinz

-- 
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/CAOQnsABkw3Ba-i4nC3rxoXqELv4d8ZNhp3h27NtF_KE4xWkvdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Deprecate Cache.has_key()?

[Tim Graham]

Any opposition to deprecating Cache.has_key()? Cache already implements 
__contains__() so converting has_key() to "in" can be done with existing 
versions of Django. Anyone using flake8 will get a warning about has_key() 
usage: W601 .has_key() is deprecated, use 'in'.

-- 
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/aa7688bf-e0bc-4ed9-a129-87be68b041f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate Cache.has_key()?

[Tim Graham]

Also the template BaseContext class has an undocumented has_key() method. I 
wonder if that can be removed without a deprecation?

https://github.com/django/django/pull/6066

On Friday, January 29, 2016 at 6:11:54 PM UTC-5, Tim Graham wrote:
>
> Any opposition to deprecating Cache.has_key()? Cache already implements 
> __contains__() so converting has_key() to "in" can be done with existing 
> versions of Django. Anyone using flake8 will get a warning about has_key() 
> usage: W601 .has_key() is deprecated, use 'in'.
>

-- 
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/afbb78c6-3288-4544-b934-26b48acd9192%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate Cache.has_key()?

[Curtis Maloney]

Isn't this so it complies with the dict interface? True, it's discouraged now, 
but it's still there.



On 30 January 2016 10:42:12 am LHDT, Tim Graham  wrote:
>Also the template BaseContext class has an undocumented has_key()
>method. I 
>wonder if that can be removed without a deprecation?
>
>https://github.com/django/django/pull/6066
>
>On Friday, January 29, 2016 at 6:11:54 PM UTC-5, Tim Graham wrote:
>>
>> Any opposition to deprecating Cache.has_key()? Cache already
>implements 
>> __contains__() so converting has_key() to "in" can be done with
>existing 
>> versions of Django. Anyone using flake8 will get a warning about
>has_key() 
>> usage: W601 .has_key() is deprecated, use 'in'.
>>
>
>-- 
>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/afbb78c6-3288-4544-b934-26b48acd9192%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/4018585A-9B06-4796-9D10-31EF6CDDF633%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Max Arnold]

What if this list of sites needs to be changed dynamically without app restart 
(multitenancy)?

On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham wrote:
> In another thread about adding a "scheme" field to the Site model [1], I 
> floated the idea of moving the data stored by the Site model into a setting:
> 
> I've sometimes thought that the Site model violates the principle that you 
> shouldn't put configuration in your database. I guess there's some 
> usefulness to having a ForeignKey to the site, but... would it be feasible 
> to offer a SITES setting that could be used instead? e.g.
> 
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }

-- 
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/20160130070141.GA2770%40otg.dm.
For more options, visit https://groups.google.com/d/optout.