Julien, I'm not describing an edge case. Django will return an HTTP
500 for ANY field lookup on a related model that is not in the
list_filter option.
To test, simply create a model that has a ForeignKey to another model
and hook it up into the admin site. Don't include any list_filter
options. Then craft a valid query string on the change list page that
queries a field on the related model. You will get an HTTP 500.
For example:
myapp/models.py:
class MyModel(models.Model):
parent = ForeignKey(AnotherModel)
myapp/admin.py
admin.site.register(MyModel)
then visit http://localhost:8000/admin/myapp/mymodel/?parent__pk=1 and
you will get a SuspiciousOperation exception with a return code of
500.
Just to be clear, I'm not against the SuspiciousOperation exception
being raised. I just think it should use a more appropriate HTTP
status code, like 403.
On Apr 11, 11:47 am, Julien Phalip <[email protected]> wrote:
> On Apr 10, 2012, at 4:34 AM, 3point2 wrote:
>
>
>
>
>
>
>
>
>
> > The admin site allows the use of certain query strings to filter
> > change list pages. The syntax follows queryset field lookups, for
> > examplehttp://mysite.com/admin/myapp/mymodel/?field__exact=test.
> > Lookups that are not specified on the ModelAdmin's list_filter option
> > raise a SuspiciousOperation exception. This is done to prevent a
> > normal user from obtaining sensitive information (e.g. password
> > hashes).
>
> > In production use, I'm not sure that returning an HTTP code of 500
> > (internal server error) and emailing the server admins is an
> > appropriate response to a user manipulating the query string.
>
> > I think that 403 (forbidden) would be more accurate. In my mind, 500
> > suggests that something went wrong on the server, for example an
> > unexpected condition or exception in the application code. In this
> > situation, this is not the case. Django is deliberately forbidding a
> > user from accessing information for which they have not been
> > authorized.
>
> > Any thoughts?
>
> I agree that no 500 response should be returned only by passing improper
> querystring parameters, unless those parameters match a custom list filter
> and that filter raises an unhandled exception. There is already a system in
> place to avoid this problem though, so if you've found an edge case could you
> please create a new ticket in Trac with a test case?
>
> Thanks a lot,
>
> Julien
>
> smime.p7s
> 1KViewDownload
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
