#25347: QueryDict can't return a list for a select multiple form element
-------------------------------------+-------------------------------------
Reporter: drakej | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: HTTP handling | Version: master
Severity: Normal | Resolution: wontfix
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 charettes):
* status: new => closed
* resolution: => wontfix
Comment:
I think there's a good reason `QueryDict.get()` doesn't return a list if a
key is specified multiple time (Compared to PHP's $_GET and $_POST) and it
shouldn't be changed. Plus this is backward incompatible.
If I use `self.request.GET.get('foo')` I'm expecting a `str` to be
returned and not a `list`. User controlled input shouldn't be allowed to
change the return type of `.get()` and possibly introduce security issues.
e.g.
{{{#!python
# This would work with ?pk=1 but cause a TypeError with ?pk=1&pk2
def view(request):
pk = request.GET.get('pk')
obj = Model.objects.get(pk=pk)
}}}
The same issue applies when using the Form api that relies on
`self.data.get`.
> This is from the documentation and it mentions that this custom class
around the post data is needed to support it, yet doesn't explain why it's
needed. No other language or framework I've worked with has this
limitation where you need to explicitly know the form element's "type"
before hand. This makes dynamically parsing the results impossible since
you need to know the type before you can actually access it correctly.
You should know before hand, independently of the form element "type"
used, if you're expecting a parameter to be a scalar or a list of element.
For example, if `get()` was modified to return a `list` if a key is
specified more than once it would still return a scalar if you selected
only one element in a `select[type=multiple]`.
Closing as ''wontfix'' since this is highly backward incompatible and
would introduce a subtle foot-gun for newcomers.
--
Ticket URL: <https://code.djangoproject.com/ticket/25347#comment:6>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.79c99dee29978717cfc50a719bc5d684%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
