Re: [Django] #27344: ConditionalGetMiddleware should only operate on GET requests (was: ConditionalGetMiddleware should not operate on unsafe requests)

2016-10-15 Thread Django 
#27344: ConditionalGetMiddleware should only operate on GET requests
-+-
 Reporter:  Kevin Christopher|Owner:  Kevin
  Henry  |  Christopher Henry
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Kevin Christopher Henry:

Old description:

> With unsafe methods (`PUT`, etc.) the appropriate conditional response
> would be a 412 Precondition Failed response, which should prevent the
> request from being carried out. But by definition
> `ConditionalGetMiddleware` acts after the response has been generated, so
> it’s too late. The PR below includes a regression test where the
> middleware inappropriately changes the response to a 412 after applying
> the unsafe operation.

New description:

 With unsafe methods (`PUT`, etc.) the appropriate conditional response
 would be a 412 Precondition Failed response, which should prevent the
 request from being carried out. But by definition
 `ConditionalGetMiddleware` acts after the response has been generated, so
 it’s too late. The PR below includes a regression test where the
 middleware inappropriately changes the response to a 412 after applying
 the unsafe operation.

 `ConditionalGetMiddleware` is not suitable for `HEAD` requests either.
 `HEAD` responses should return the same headers (including the `ETag`) as
 the corresponding `GET` response, but `ConditionalGetMiddleware` will only
 see the empty response body of the `HEAD` response and so will compute the
 wrong `ETag`. Trying to compare `ETags` in this situation is also
 pointless, as [https://tools.ietf.org/html/rfc7232#section-5 pointed out]
 in the specification:

 > Although conditional request header fields are defined as being usable
 with the `HEAD` method (to keep `HEAD`'s semantics consistent with those
 of `GET`), there is no point in sending a conditional `HEAD` because a
 successful response is around the same size as a 304 (Not Modified)
 response and more useful than a 412 (Precondition Failed) response.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f239bd7b6744cffc01f1f07233fbdbe6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27353: BooleanField raises ValidationError always for RadioSelect widget value False

2016-10-15 Thread Django 
#27353: BooleanField raises ValidationError always for RadioSelect widget value
False
+--
 Reporter:  wbar|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  1.10
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug


Comment:

 I don't think this is a bug. As
 [https://docs.djangoproject.com/en/stable/ref/forms/fields/#booleanfield
 the docs] say,

  Since all `Field` subclasses have `required=True` by default, the
 validation condition here is important. If you want to include a boolean
 in your form that can be either `True` or `False` (e.g. a checked or
 unchecked checkbox), you must remember to pass in `required=False` when
 creating the `BooleanField`.

 Maybe you want to use `TypedChoiceField` instead.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.6d1ae7475955bfba376bd09bd6bf4367%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27353: BooleanField raises ValidationError always for RadioSelect widget value False

2016-10-15 Thread Django 
#27353: BooleanField raises ValidationError always for RadioSelect widget value
False
---+
 Reporter:  wbar   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 **Model:**
 {{{
 class MyModel(models.Model):
 buggy_field = models.BooleanField(default=False
 }}}

 **Form:**
 {{{
 class MyForm(forms.ModelForm):
 buggy_field = forms.BooleanField(
 widget=forms.RadioSelect(choices=[(True, 'Tak'), (False, 'Nie')]),)
 }}}


 Buggy place because value is False here:
 **django.forms.fields.py+718:**
 {{{
 def validate(self, value):
 if not value and self.required:
 raise ValidationError(self.error_messages['required'],
 code='required')
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.12c477305be23ed9a20d130a04d32e97%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27352: Warn about social media fingerprinting when using redirect_authenticated_user

2016-10-15 Thread Django 
#27352: Warn about social media fingerprinting when using
redirect_authenticated_user
-+-
 Reporter:  Markus Holtermann|Owner:  Markus
 Type:   |  Holtermann
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Markus Holtermann):

 * needs_docs:  1 => 0
 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/7403

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.88b8e4e17fb0d5b03e1f5971c990678d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27352: Warn about social media fingerprinting when using redirect_authenticated_user

2016-10-15 Thread Django 
#27352: Warn about social media fingerprinting when using
redirect_authenticated_user
-+-
   Reporter:  Markus |  Owner:  Markus Holtermann
  Holtermann |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  1.10
  Documentation  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Public disclosure after talking with security team.

 Django 1.10 introduced `redirect_authenticated_user` to the login views. A
 report I came across the other day (https://robinlinus.github.io
 /socialmedia-leak/) points out how that redirects on GET for authenticated
 users can potentially be used to gain the login state of a user for a
 site.

 I believe we should warn users about that issue. Reverting
 10781b4c6ff981f581157957d221e7621e0bf4ed (#12233) doesn't seem necessary
 to me. It is a useful feature if you know you don't serve image files from
 those domains.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.5caa3827b39585640b2de8a07a6544c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27351: A Django field consisting of several fields

2016-10-15 Thread Django 
#27351: A Django field consisting of several fields
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aymeric Augustin):

 #373 isn't about multiple primary keys. It's about a single primary key
 that is split across several fields in the database, also called a
 composite primary key. A well-designed, framework-level solution to the
 problem you described would solve #373 and vice versa. So I agree with Tim
 when he says it's a duplicate.

 Outside of primary keys (and perhaps other relational fields, you didn't
 give enough details about your use case to tell on which side it falls)
 you can easily manage this at the application level: implement a read-
 write property to proxy access to the underlying fields and you're done.
 So the problem that needs solving in Django is composite primary keys. The
 solution is to introduce a composite fields, which is what you described,
 as far as I understand.

 Since you asked for advice:

 1. When the person who's paid to keep tabs on all development efforts
 tells you where to start, pay attention instead of brushing off their
 advice in less than 5 minutes, or else don't ask for advice in the first
 place.

 2. The order of magnitude of the work required to fix this is likely
 hundred hours for an experienced contributor. If it was significantly
 easier, I think it would have been done. The two GSoC devoted to this
 problem didn't suffice. No offense meant, but you're talking about a well
 understood problem and you don't describe it in a way that acknowledges
 previous efforts in this area.

 3. To tackle this, in addition to #373, everything Michal Petrucha wrote
 about his GSoCs, and everything Thomas Stephenson wrote when he formalized
 DEP 191, you should review related discussions on the django-developers
 mailing list and figure out which parts of the design are solved and which
 parts aren't, what code was written and why it couldn't be merged. The
 meta refactor may help; if memory serves the interactions with composite
 fields came up in the mailing-list discussions.

 4. The next step would be to revise DEP 191 and post the resulting
 proposal to django-developers.

 5. Your description mixes up form fields and model fields. If the
 difference is unclear to you, you need to familiarize yourself with the
 Django code base before tackling this. If the difference is clear to you,
 then you should pay attention to using accurate terms.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2d38c0adf3145fcb098fb5e11c071ef8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27351: A Django field consisting of several fields

2016-10-15 Thread Django 
#27351: A Django field consisting of several fields
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Victor Porton):

 * status:  closed => new
 * resolution:  duplicate =>


Comment:

 It isn't a duplicate of #373. #373 asks about multiple **primary** keys
 while I ask for a field consisting of several "smaller" field (which are
 not necessary primary keys).

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fb58f69b02890d3d136f4cd33d6b6f11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27351: A Django field consisting of several fields

2016-10-15 Thread Django 
#27351: A Django field consisting of several fields
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 It's not easy. See #373 for discussion and past attempts.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e3cadcf997e7851d29a012410c71b5ea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27351: A Django field consisting of several fields

2016-10-15 Thread Django 
#27351: A Django field consisting of several fields
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Victor Porton):

 * cc: porton@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2586cf44977e888bbf2e8446f96dd04a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27351: A Django field consisting of several fields

2016-10-15 Thread Django 
#27351: A Django field consisting of several fields
--+
 Reporter:  Victor Porton |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I want a "composite" Django fields which corresponds to two (rather than
 one) database columns.

 In fact the composite field should consist of two ForeignKey fields.

 Otherwise it should behave like a normal field. For example it can be used
 in a form to input data.

 It seems that Django 1.10.1 does not support this. I may try to write a
 patch. Any advice?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.fa90ed586c3f5ff61a461bc0c528ecf0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20888: Allow defining order of column for indexes

2016-10-15 Thread Django 
#20888: Allow defining order of column for indexes
-+-
 Reporter:  anonymous|Owner:  Akshesh
 |  Doshi
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  index, order, db-| Triage Stage:  Ready for
  indexes 1.11   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e7316fb8cd437238c2f362f3d32655a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.