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 > example http://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
Description: S/MIME cryptographic signature
