#22406: Inconsistent way to parse boolean value from posted data
--------------------------+--------------------------------------
     Reporter:  xiaowl@…  |                    Owner:  nobody
         Type:  Bug       |                   Status:  closed
    Component:  Forms     |                  Version:  1.6
     Severity:  Normal    |               Resolution:  needsinfo
     Keywords:            |             Triage Stage:  Unreviewed
    Has patch:  1         |      Needs documentation:  0
  Needs tests:  0         |  Patch needs improvement:  0
Easy pickings:  0         |                    UI/UX:  0
--------------------------+--------------------------------------

Comment (by Thomas Hamann):

 Replying to [comment:3 Christian Kreuzberger]:
 > A similar inconsistency still exists in 1.11 with BooleanFields and
 NullBooleanFields in django.forms:
 >
 > NullBooleanField uses the NullBooleanSelect widget, while BooleanField
 uses the CheckboxInput widget:
 >
 > BooleanField uses django.forms.widget.CheckboxInput which evaluates
 'true','True',True,'1' to True, and 'false','False',False,'0' to False -
 which is fine.
 >
 >
 > But NullBooleanField uses NullBooleanSelect, which as stated above, does
 NOT evaluate 'false' to False, and not 'true' to True. Instead, it
 evalutes '2' and 'True' to True, '3' and 'False' to False...
 >
 This same behaviour in combination with a Google Chrome/Chromium 'feature'
 leads to some very unexpected behaviour that may cause people to assume
 their APIs are broken.

 In Chrome and many Chromium-based browsers first submitting a URL of the
 form:

 /my/site/?show_only_assigned_tasks=true

 and then re-submitting it as:

 /my/site/?show_only_assigned_tasks=True

 causes the browser to assume that the same URL was entered twice because
 the page caching mechanism apparently does not check on case-sensitivity!
 Apparently this is by design...

 As mentioned by Christian this works out fine for BooleanFields, but due
 to the inconsistency in the NullBooleanField string handling the API will
 seem to keep failing even when using the correctly capitalized URL after
 first using the wrongly capitalized one in Chrome/Chromium.

 There are two user-side solutions that do not involve using Christian's
 solution, and both are user-unfriendly:
 - empty browser cache
 - disable certain security settings

 It would be better if Django 1.11 could be patched to fix the issue.

 I don't know whether this same behaviour happens in Django 2.0 or above
 when using Chrome or Chromium, but it may be worth checking because just
 making a user click on intentionally wrong URLs in Chrome can result in a
 seemingly broken Django site.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/22406#comment:4>
Django <https://code.djangoproject.com/>
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.b9ecf5ab9ffa72d8b65f7d0e4359a1d4%40djangoproject.com.

Reply via email to