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

[Anssi Kääriäinen]

I'm with Tim here - we shouldn't alter the behavior at this point.

On Thu, Feb 4, 2016 at 8:17 AM, Chris Foresman  wrote:
> I don't think that's the same thing. We're talking about interfacing with a
> system that has clearly delineated values.
>>
>> The boolean type can have several states: "true", "false", and a third
>> state, "unknown", which is represented by the SQL null value.[1]
>
>
> While the database accepts a variety of optional string literals to insert
> true or false, none of them are truly comparable to Python's truth-y or
> false-y values. For instance, psycopg2 only uses True, False, and None to
> represent TRUE, FALSE, and NULL in the database.[2] That's why values passed
> to filter on a BooleanField are cast to bool.
>
> While allowing some slop might be considered more "Pythonic" is some cases,
> I feel "explicit is better then implicit" in this case given that SQL
> doesn't allow boolean columns to be set in an implicit "Pythonic"
> truth-y/false-y way.
>
>
> [1](http://www.postgresql.org/docs/9.1/static/datatype-boolean.html)
> [2](http://initd.org/psycopg/docs/usage.html#constants-adaptation)
>
>
> On Tuesday, February 2, 2016 at 4:23:37 AM UTC-6, HM wrote:
>>
>> I don't think enforcing it would be pythonic.
>>
>> Once upon a time, Python lacked True and False, all you had were
>> truthy and falsey and maybe per-project/team constants:
>>
>> http://python-history.blogspot.no/2013/11/story-of-none-true-false.html
>>
>> I remember the arguments when bool() was added. Those against were
>> worried that it would send a signal that would lead to a slippery
>> slope where truthy and falsey would disappear because people would
>> insist that "it's pretty sloppy to not enforce an explicit boolean
>> value and can lead to subtle bugs".
>>
>> Well..
>>
>>
>> On 31 January 2016 at 10:34, Adam Johnson  wrote:
>> > Just to play devil's advocate... you're all worrying about one simple
>> > case;
>> > there are infinite variants of it with subtle bugs, for example imagine
>> > the
>> > same situation but with Value:
>> >
>> > Whatever.object.filter(is_active=Value('false'))
>> >
>> > The ORM can't predict the type of a Value call - pretty much by
>> > definition,
>> > since it's a raw value passed to the database. So you might be able to
>> > fix
>> > BooleanField for a few cases, but you can't fix them all..
>> >
>> >
>> >
>> > On Friday, January 29, 2016 at 10:38:52 PM UTC, Chris Foresman wrote:
>> >>
>> >> 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 

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

[Chris Foresman]

I don't think that's the same thing. We're talking about interfacing with a 
system that has clearly delineated values.

> The boolean type can have several states: "true", "false", and a third 
> state, "unknown", which is represented by the SQL null value.[1]


While the database accepts a variety of optional string literals to insert 
true or false, none of them are truly comparable to Python's truth-y or 
false-y values. For instance, psycopg2 only uses True, False, and None to 
represent TRUE, FALSE, and NULL in the database.[2] That's why values 
passed to filter on a BooleanField are cast to bool.

While allowing some slop might be considered more "Pythonic" is some cases, 
I feel "explicit is better then implicit" in this case given that SQL 
doesn't allow boolean columns to be set in an implicit "Pythonic" 
truth-y/false-y way.


[1](http://www.postgresql.org/docs/9.1/static/datatype-boolean.html)
[2](http://initd.org/psycopg/docs/usage.html#constants-adaptation)


On Tuesday, February 2, 2016 at 4:23:37 AM UTC-6, HM wrote:
>
> I don't think enforcing it would be pythonic. 
>
> Once upon a time, Python lacked True and False, all you had were 
> truthy and falsey and maybe per-project/team constants: 
>
> http://python-history.blogspot.no/2013/11/story-of-none-true-false.html 
>
> I remember the arguments when bool() was added. Those against were 
> worried that it would send a signal that would lead to a slippery 
> slope where truthy and falsey would disappear because people would 
> insist that "it's pretty sloppy to not enforce an explicit boolean 
> value and can lead to subtle bugs". 
>
> Well.. 
>
>
> On 31 January 2016 at 10:34, Adam Johnson  
> wrote: 
> > Just to play devil's advocate... you're all worrying about one simple 
> case; 
> > there are infinite variants of it with subtle bugs, for example imagine 
> the 
> > same situation but with Value: 
> > 
> > Whatever.object.filter(is_active=Value('false')) 
> > 
> > The ORM can't predict the type of a Value call - pretty much by 
> definition, 
> > since it's a raw value passed to the database. So you might be able to 
> fix 
> > BooleanField for a few cases, but you can't fix them all.. 
> > 
> > 
> > 
> > On Friday, January 29, 2016 at 10:38:52 PM UTC, Chris Foresman wrote: 
> >> 
> >> 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 
> > 

Re: Feature proposal: selection of views and tables for inspectdb

[José Tomás Tocino]

Sorry I've been pretty disconnected from this thread. 

The TL;DR version of the current situation is as follows: in Oracle, if a 
user has read access to tables/views not owned by him, those are not listed 
by the inspection mechanism inspectdb uses, so no model is generated for 
them. They can be inspected if their name is explicitly given though. My PR 
just offered a way of manually choosing what tables/views should be 
introspected and have code generated for them.

The solution proposed by the user Jani Tiainen in extending the 
functionality of my PR so that you can use wildcards to easily match more 
than one table/view.

If no more complexity is to be added, then the solution would be fixing the 
SQL I mentioned before [1] so that it correctly reports tables the user can 
read... and also removes support to introspect views to properly match the 
expected functionality of inspectdb (that in theory should not introspect 
views). I think the key would be using the ALL_TABLES view in Oracle 
instead of the USER_TABLES view, as it's suggested here [2]. This solution 
is the one that more closely matches your desires, Tim.



[1] 
: 
https://github.com/django/django/blob/53ccffdb8c8e47a4d4304df453d8c79a9be295ab/django/db/backends/oracle/introspection.py#L54
[2] : http://stackoverflow.com/a/205746/276451

El jueves, 19 de noviembre de 2015, 2:30:24 (UTC+1), Tim Graham escribió:
>
> One correction, inspectdb doesn't currently create models for views, but 
> this isn't the first time that code caused confusion, see 
> https://code.djangoproject.com/ticket/25038.
>
> I agree that fixing the inspect SQL would be the ideal solution. José, I 
> didn't follow the conversation closely enough to tell if you presented a 
> reason this infeasible for some reason? I'd rather not add more complexity 
> (arguments to inspectdb) where an easy solution already exists (removing 
> unwanted models from the generated output). 
>
> On Wednesday, November 11, 2015 at 7:40:49 AM UTC-5, Jani Tiainen wrote:
>>
>> Hi,
>>
>> I guess it's just about crafting proper SQL for Oracle to do proper 
>> introspection and do a PR to be inline with other backends what comes to 
>> table/view discovery.
>>
>> On 11.11.2015 14:14, José Tomás Tocino wrote:
>>
>> So... is this going anywhere?
>>
>> El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
>> escribió: 
>>>
>>> Well maybe extending queries to do that. Wonder is there similiar issues 
 with postgresql?

>>>
>>> Nope, I've just tried granting SELECT access to a user and he can 
>>> inspect the tables properly (in postgresql):
>>>
>>> postgres=# CREATE DATABASE permissions;
>>> CREATE DATABASE
>>> postgres=# \c permissions;
>>> You are now connected to database "permissions" as user "postgres".
>>> permissions=# create table foo (id int, name varchar(255));
>>> CREATE TABLE
>>> permissions=# GRANT CONNECT ON DATABASE permissions to tester;
>>> GRANT
>>> permissions=# GRANT USAGE ON SCHEMA public TO tester;
>>> GRANT
>>> permissions=# GRANT SELECT ON foo TO tester;
>>> GRANT
>>> permissions=# \q
>>> (ENV)vagrant@vagrant-ubuntu-trusty-64:~$ ./manage.py inspectdb
>>> # This is an auto-generated Django model module.
>>> # You'll have to do the following manually to clean this up:
>>> #   * Rearrange models' order
>>> #   * Make sure each model has one field with primary_key=True
>>> #   * Remove `managed = False` lines if you wish to allow Django to 
>>> create, modify, and delete the table
>>> # Feel free to rename the models, but don't rename db_table values or 
>>> field names.
>>> #
>>> # Also note: You'll have to insert the output of 'django-admin sqlcustom 
>>> [app_label]'
>>> # into your database.
>>> from __future__ import unicode_literals
>>>
>>> from django.db import models
>>>
>>>
>>> class Foo(models.Model):
>>> id = models.IntegerField(blank=True, null=True)
>>> name = models.CharField(max_length=255, blank=True, null=True)
>>>
>>> class Meta:
>>> managed = False
>>> db_table = 'foo'
>>>
>>>
>>> So there's that
>>>  
>>>

 -- 
 José Tomás Tocino García
 http://www.josetomastocino.com
 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 
 https://groups.google.com/d/
 msgid/django-developers/CAAOwDo7J33ScxGvQ3UZe2HLMLbc1Eim1TPGwqFDap6Xdp%2BJkFw%
 40mail.gmail.com.
 For more options, visit https://groups.google.com/d/optout.


 -- 
>> 

Re: remove support for unsalted password hashers?

[Tim Graham]

Acknowledged Donald, I just didn't want to bite off too much at once.

I think the unsalted hashers removal could be done as a 
backwards-incompatible change. I wrote up some documentation including 
queries to check if your database is affected: 
https://github.com/django/django/pull/6082
I'll be curious to know if anyone has a project that started in the Django 
0.90 era which returns some results for those queries.

About removing the SHA1PasswordHasher, MD5PasswordHasher, and/or 
CryptPasswordHasher -- I suspect many more users will be affected, so the 
normal deprecation process seems appropriate. To give an example, 8,484 
(64%) of the passwords for djangoproject.com users are SHA1. If the SHA1 
hasher is deprecated, what would we do? Options I can think of:

1. copy the hasher into the djangoproject.com source
2. release the legacy hashers as a separate package for those projects that 
need them
3. mark old passwords as unusable and force a reset if one of those users 
comes back

The max "last login" for a user with a SHA1 hash is February 2013.

Also, the MD5PasswordHasher is suggested in the documentation as a way to 
speed up tests so we would need to change that, whether it's force_login() 
or some new "no-op test hasher" .

On Tuesday, February 2, 2016 at 2:20:44 PM UTC-5, Donald Stufft wrote:
>
>
> On Feb 2, 2016, at 1:52 PM, Tim Graham  
> wrote:
>
> Just to be clear, my proposal here is only about removing 
> UnsaltedSHA1PasswordHasher and UnsaltedMD5PasswordHasher. The salted 
> versions of these hashers remain.
>
>
>
> It seems silly to remove the unsalted options and leave the salted 
> options, they are basically equally [1] as secure since computational power 
> is such that it is, that it’s not really worth it to use rainbow tables 
> anymore anyways.
>
> [1] Ok, Ok, technically salted are a wee bit more secure, but given that 
> you can compute the MD5 of every single possible lower case alpha numeric 
> of 6 characters or less in under a minute on a single regular 
> desktop/server.. I don’t believe the distinction is useful.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
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/66c31c07-5f7b-4817-83e8-2e7a5660ec97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26165 new Cleanup/optimization wanted to start with a documentation ticket

[Vivek unni]

Thanks for helping me out. Sorry for the mess up regarding the Triage 
stage. Thanks for walking me through the whole process. 


-- 
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/f8a9c32d-6b11-423d-9a30-6b8957a6e6d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Baxter]

What would be the recommendation for assigning content to a particular site 
in a shared DB model? Integer field with the current SITE_ID to create a 
sort of faux FK or M2M? Choices?

One thing I like about this pattern I haven't seen discussed already is 
that it would make it far easier to extend Sites as need. For example, one 
request I've had is the ability to store some additional information on 
Sites beyond name and domain. This would provide a pretty straightforward 
mechanism to do so.

-- 
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/53b7ac67-f4c5-4f4a-b175-a3df9172a39c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove null assingment check for non-nullable fields?

[Florian Apolloner]

On Wednesday, February 3, 2016 at 12:26:26 AM UTC+1, Tim Graham wrote:
>
> There's a proposal to remove this behavior:
>
>
> >>> obj.fk = None
> ValueError('Cannot assign None: "Obj.fk" does not allow null values.)
>

Yes please, if you do IntegerField(null=False) you can still do 
instance.xxx = None -- only ForeignKeys are weird and check during 
assignment…
That said I thought we already removed that in 1.9 or 1.10?

-- 
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/e1a906de-bad7-478d-831d-551b785a0ef1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25897 - managers defined on non-abstract base classes inherited by child classes

[Tim Graham]

Could this go through a deprecation where any use of the inherited managers 
to be removed will raise a warning for a couple releases? If anyone is 
relying on the behavior, they just need to add the managers to any 
subclasses, correct?

On Wednesday, February 3, 2016 at 9:16:41 AM UTC-5, Alex Poleha wrote:
>
> Hi. 
>
> According to documentation 
> 
>  managers 
> defined on non-abstract base classes are not inherited by child classes. In 
> fact they're inherited via python MRO. I made pull request 
>  to fix it. I find this 
> inheritance embarrassing due to reasons, explained in documentation:
>
>1. Managers defined on non-abstract base classes are *not* inherited 
>by child classes. If you want to reuse a manager from a non-abstract base, 
>redeclare it explicitly on the child class. These sorts of managers are 
>likely to be fairly specific to the class they are defined on, so 
>inheriting them can often lead to unexpected results (particularly as far 
>as the default manager goes). Therefore, they aren’t passed onto child 
>classes.
>
> I also think this example shows some reasons why this inheritance is 
> embarrasing:
>
> class SimpleComment(models.Model):
> test_objects = models.Manager()
>
>
> class BaseComment(models.Model):
> pass
>
>
> class Comment(BaseComment):
> test_objects = models.Manager()
>
> print(hasattr(models.SimpleComment, 'objects')) #False
> print(hasattr(models.Comment, 'objects'))  #True, we may expect False 
> here, since 'SimpleComment' gives False in similar sitation.
> print(models.Comment.objects.model) #, this manager 
> is not contributed to 'Comment' class
>
> Tim Graham suggests asking if anyone relying on this inheritance and 
> documentation should be fixed instead. Any suggestions?
>

-- 
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/4b744e92-7549-49b5-9b9b-b6158e53bb78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26165 new Cleanup/optimization wanted to start with a documentation ticket

[Tim Graham]

Please send the pull request -- we do review there, not on this mailing 
list. Thanks!

On Wednesday, February 3, 2016 at 10:27:32 AM UTC-5, Vivek unni wrote:
>
> Hi. I have compiled a list of questions. I made a section in the faq 
> folder. These are the questions and answers I wrote. These answers were 
> written based on the thread referenced on the ticket
>
> FAQ: CSRF Protection
> =
>
> Is Django's CSRF protection vulnerable?
> ---
>
> No, it is not. Django CSRF security system provides an implementation that 
> allows you to have CSRF protection without linking it to a session. The way 
> the CSRF token works is simple. Every form will have a CSRF token which 
> matches the CSRF cookies. While processing the submitted form, the server 
> will make sure that the submitted CSRF token matches the cookie value. This 
> is a server side check but it is not against any stored server-side value. 
> Since the remote attacker would not be able to read or set arbitrary 
> cookies on your domain, it protects the user.
>
> Why can't we keep a new token for each request ?
> 
>
> Generating a new token for each request is problematic from a UI 
> perspective because it invalidates all previous forms. Most users would be 
> very unhappy to find that opening a new tab on your site has invalidated 
> the form they had just spent time filling out in the other tab or that a 
> form they accessed via the back button could not be filled out.
>
> How can I make Django's CSRF protection work to its full extent ?
> --
>
> Make sure of the following:
>
> * Use HTTPS.Redirect to the encrypted version for all unencrypted 
> requests. If you don't do this,
>   CSRF protection won't be able to protect you from a man-in-the-middle 
> attack.
>
> * Use HSTS. Set it for several months. Use "includeSubDomains". This means 
> that no matter what your
>   users type, and no matter what the man-in-the-middle does, your users 
> will always access your site securely if they've been there at least once 
> before.
>
> * Validate the HOST header in your httpd. Don't allow arbitrary requests 
> to fall through to Django.
>   Serve your site only for the appropriate domain. See the most recent 
> security advisory for more information about this.
>
> * Ensure there are no XSS vulnerabilities on your website.
>
> If the above mentioned points are enforced then the developer will be able 
> to take advantage of the other feature that makes the CSRF protection 
> stronger: Strict referer checking (only enforced over HTTPS). This means 
> that even if a subdomain can set or modify cookies on your domain, they 
> can't force a visitor to post to your application, since that request won't 
> come from your own exact domain.
>
> Is this fine or should I add more ? If this is fine, I can send a pull 
> request today itself.
>

-- 
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/11d75e9d-32a6-4c87-8977-6583fb338312%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26165 new Cleanup/optimization wanted to start with a documentation ticket

[Vivek unni]

Hi. I have compiled a list of questions. I made a section in the faq 
folder. These are the questions and answers I wrote. These answers were 
written based on the thread referenced on the ticket

FAQ: CSRF Protection
=

Is Django's CSRF protection vulnerable?
---

No, it is not. Django CSRF security system provides an implementation that 
allows you to have CSRF protection without linking it to a session. The way 
the CSRF token works is simple. Every form will have a CSRF token which 
matches the CSRF cookies. While processing the submitted form, the server 
will make sure that the submitted CSRF token matches the cookie value. This 
is a server side check but it is not against any stored server-side value. 
Since the remote attacker would not be able to read or set arbitrary 
cookies on your domain, it protects the user.

Why can't we keep a new token for each request ?


Generating a new token for each request is problematic from a UI 
perspective because it invalidates all previous forms. Most users would be 
very unhappy to find that opening a new tab on your site has invalidated 
the form they had just spent time filling out in the other tab or that a 
form they accessed via the back button could not be filled out.

How can I make Django's CSRF protection work to its full extent ?
--

Make sure of the following:

* Use HTTPS.Redirect to the encrypted version for all unencrypted requests. 
If you don't do this,
  CSRF protection won't be able to protect you from a man-in-the-middle 
attack.

* Use HSTS. Set it for several months. Use "includeSubDomains". This means 
that no matter what your
  users type, and no matter what the man-in-the-middle does, your users 
will always access your site securely if they've been there at least once 
before.

* Validate the HOST header in your httpd. Don't allow arbitrary requests to 
fall through to Django.
  Serve your site only for the appropriate domain. See the most recent 
security advisory for more information about this.

* Ensure there are no XSS vulnerabilities on your website.

If the above mentioned points are enforced then the developer will be able 
to take advantage of the other feature that makes the CSRF protection 
stronger: Strict referer checking (only enforced over HTTPS). This means 
that even if a subdomain can set or modify cookies on your domain, they 
can't force a visitor to post to your application, since that request won't 
come from your own exact domain.

Is this fine or should I add more ? If this is fine, I can send a pull 
request today itself.

-- 
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/816bad89-48dd-45b1-a166-92bfd1ee86a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bank of examples.

[Katherine Michel]

You might also want to check out https://djangosnippets.org though I'm sure 
that many of these examples are before 1.9

On Wednesday, 13 January 2016 08:30:06 UTC-6, Parki wrote:
>
> I've just started out to learn Django and I realize how great would be if 
> we had a bank of Django examples.
> I would have it, so I want you to contribute.
> https://github.com/Parki0/djangoexamples
>

-- 
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/339ff9e4-ace9-4051-ba6f-fb87ee943d0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#25897 - managers defined on non-abstract base classes inherited by child classes

[Alex Poleha]

Hi. 

According to documentation 

 managers 
defined on non-abstract base classes are not inherited by child classes. In 
fact they're inherited via python MRO. I made pull request 
 to fix it. I find this 
inheritance embarrassing due to reasons, explained in documentation:

   1. Managers defined on non-abstract base classes are *not* inherited by 
   child classes. If you want to reuse a manager from a non-abstract base, 
   redeclare it explicitly on the child class. These sorts of managers are 
   likely to be fairly specific to the class they are defined on, so 
   inheriting them can often lead to unexpected results (particularly as far 
   as the default manager goes). Therefore, they aren’t passed onto child 
   classes.

I also think this example shows some reasons why this inheritance is 
embarrasing:

class SimpleComment(models.Model):
test_objects = models.Manager()


class BaseComment(models.Model):
pass


class Comment(BaseComment):
test_objects = models.Manager()

print(hasattr(models.SimpleComment, 'objects')) #False
print(hasattr(models.Comment, 'objects'))  #True, we may expect False here, 
since 'SimpleComment' gives False in similar sitation.
print(models.Comment.objects.model) #, this manager is 
not contributed to 'Comment' class

Tim Graham suggests asking if anyone relying on this inheritance and 
documentation should be fixed instead. Any suggestions?

-- 
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/d0b0f36a-28eb-40a1-8124-2a888b810c87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin Improvement - Autocomplete & improved search for FKs

[Cristiano Coelho]

Nice, I guess my google skills are quite bad since I looked for it and 
didn't find it :)

Opened 5 years ago with progress but still not completed, looks like it may 
need some help

El miércoles, 3 de febrero de 2016, 9:13:54 (UTC-3), Tim Graham escribió:
>
> Here is an accepted ticket for autocomplete: 
> https://code.djangoproject.com/ticket/14370
>
> The "improved search" seems like what we already have when using 
> raw_id_fields so it seems like it should be easy to include as part of the 
> autocomplete UI. I don't see think it needs to be a separate option.
>
> On Tuesday, February 2, 2016 at 10:20:07 PM UTC-5, Cristiano Coelho wrote:
>>
>>
>> 
>>
>>
>> 
>> Hello,
>>
>> On one of my projects I'm using django-grappelli to improve the admin 
>> site ( https://github.com/sehmaschine/django-grappelli ) which was used 
>> before the very nice face wash the admin interface received on 1.9. So 
>> right now if I were to update to 1.9, the only thing I would use from this 
>> library would be the autocomplete and improved search features for foreign 
>> key models (includes inlines as well) and some other very minor features 
>> since the 1.9 interface is quite nicer.
>>
>> What's Autocomplete like? Basically, rather than a standard dropdown for 
>> foreign keys, you have a textfield where you can search and it then 
>> populate, the library implements it adding an additional required static 
>> method to models so you indicate which fields should be searched through 
>> (however in my opinion that should actually go into the ModelAdmin 
>> definition) and then jqueryui autocomplete and some other javascript plus 
>> required urls for this. I think anyone around knows how an auto complete 
>> works.
>>
>> Then for the improved search, which is a second option (you may use one, 
>> both or none), the library adds a small search button next to the dropdown 
>> (or textbox) which will open in a pop up (I actually don't like it being a 
>> pop up at all) which simply contains the actual list page for that model 
>> (the one from the FK dropdown/textbox) having all the advantages of the 
>> features you implemented for that model (ie searching, filtering, sorting, 
>> etc)
>> I have attached some screenshots of these two to help understand it.
>>
>> There are other minor feature that are nice also, like the ability to 
>> collapse inline models, or to use dropdowns for the filtering on the right 
>> rather than displaying all values (which makes it really bad for big 
>> tables).
>>
>> So these two features are quite nice, but installing a complete external 
>> library that is made for quite more (pretty much change everything on the 
>> admin page) seems like a bad idea. 
>> *Would it be worth it to have these two features implemented into django?*
>>
>> There are also other projects just to add the autocomplete feature which 
>> I haven't used nor tested ( 
>> https://django-autocomplete-light.readthedocs.org/en/master/ and 
>> https://github.com/crucialfelix/django-ajax-selects ) so the feature 
>> looks required.
>>
>>
>>
>>
>>
>>
>>

-- 
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/860e4e41-b893-4b8d-b0d3-17bc98dc1c67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Admin Improvement - Autocomplete & improved search for FKs

[Tim Graham]

Here is an accepted ticket for autocomplete: 
https://code.djangoproject.com/ticket/14370

The "improved search" seems like what we already have when using 
raw_id_fields so it seems like it should be easy to include as part of the 
autocomplete UI. I don't see think it needs to be a separate option.

On Tuesday, February 2, 2016 at 10:20:07 PM UTC-5, Cristiano Coelho wrote:
>
>
> 
>
>
> 
> Hello,
>
> On one of my projects I'm using django-grappelli to improve the admin site 
> ( https://github.com/sehmaschine/django-grappelli ) which was used before 
> the very nice face wash the admin interface received on 1.9. So right now 
> if I were to update to 1.9, the only thing I would use from this library 
> would be the autocomplete and improved search features for foreign key 
> models (includes inlines as well) and some other very minor features since 
> the 1.9 interface is quite nicer.
>
> What's Autocomplete like? Basically, rather than a standard dropdown for 
> foreign keys, you have a textfield where you can search and it then 
> populate, the library implements it adding an additional required static 
> method to models so you indicate which fields should be searched through 
> (however in my opinion that should actually go into the ModelAdmin 
> definition) and then jqueryui autocomplete and some other javascript plus 
> required urls for this. I think anyone around knows how an auto complete 
> works.
>
> Then for the improved search, which is a second option (you may use one, 
> both or none), the library adds a small search button next to the dropdown 
> (or textbox) which will open in a pop up (I actually don't like it being a 
> pop up at all) which simply contains the actual list page for that model 
> (the one from the FK dropdown/textbox) having all the advantages of the 
> features you implemented for that model (ie searching, filtering, sorting, 
> etc)
> I have attached some screenshots of these two to help understand it.
>
> There are other minor feature that are nice also, like the ability to 
> collapse inline models, or to use dropdowns for the filtering on the right 
> rather than displaying all values (which makes it really bad for big 
> tables).
>
> So these two features are quite nice, but installing a complete external 
> library that is made for quite more (pretty much change everything on the 
> admin page) seems like a bad idea. 
> *Would it be worth it to have these two features implemented into django?*
>
> There are also other projects just to add the autocomplete feature which I 
> haven't used nor tested ( 
> https://django-autocomplete-light.readthedocs.org/en/master/ and 
> https://github.com/crucialfelix/django-ajax-selects ) so the feature 
> looks required.
>
>
>
>
>
>
>

-- 
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/2b592a9e-378e-4f41-9380-d72cf00af47f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [admin] submit_row template tag reusability issue

[Federico Capoano]

Updated the ticket and sent a PR, I report the comment here too for 
convenience:

Just opened PR https://github.com/django/django/pull/6078.

A more paranoid test could be written, like creating a custom app with an 
admin that extends the context, loads a modified version of the subimt_row 
template and check the extended context is available in the template. But I 
think all the complexity needed wouldn't add much value.

Federico


On Tuesday, February 2, 2016 at 5:13:26 PM UTC+1, Tim Graham wrote:
>
> The patch is 5 years old and doesn't apply cleanly, so it needs 
> improvement in that sense but that shouldn't be difficult. The main blocker 
> to getting it merged looks like "Needs tests."
>
> On Tuesday, February 2, 2016 at 10:58:40 AM UTC-5, Federico Capoano wrote:
>>
>> Hi Tim,
>>
>> thank you for letting me know of the open ticket.
>> The "patch needs improvement" flag is set to "no". Is that correct or not?
>>
>> Federico
>>
>> On Mon, Feb 1, 2016 at 1:18 PM Tim Graham  wrote:
>>
>>> Here is an accepted ticket: https://code.djangoproject.com/ticket/13875
>>>
>>> Feel free to update and/or improve the patch, add tests, and send a pull 
>>> request. Thanks!
>>>
>>>
>>> On Monday, February 1, 2016 at 6:18:35 AM UTC-5, Federico Capoano wrote:

 Hi all,

 I came across the need of modifying the submit row functionality in the 
 django admin and I found out a small issue which prevents me from 
 modifying 
 the template without rewriting (duplicating) also the templatetag entirely.

 If you take a look at the code of submit_row templatetag 
 ,
  
 you will notice the original view context is not passed entirely to the 
 return statement. A new ctx dictionary is created and filled only with a 
 smaller subset of key/value pairs.

 I took a quick look at other template tags and I noticed they return 
 the entire context and not a stripped version of it.

 I would prefer submit_row to behave in the same way as the other 
 templatetags so I wouldn't have to duplicate its code to add new context 
 values to it.
 If there's consensus on this issue I can create a ticket and send a 
 pull request, let me know.

 Federico

>>> -- 
>>> 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/yrngp53RvxY/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/bbb82460-8a55-47ff-8e7f-acfc063f6cf0%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/6a8e218c-6d00-40c4-9a37-58a58961aaf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.