#25697: Default error views shouldn't silence TemplateDoesNotExist errors if a
custom template name was specified
--------------------------------------+------------------------------------
Reporter: charettes | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Generic views | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
--------------------------------------+------------------------------------
Description changed by charettes:
Old description:
> Default error views attempt to load a template from a default name and
> fallback to a string value if a `TemplateDoesNotExist` error is raised in
> the process.
>
> This behavior should be altered to actually raise the error if a custom
> `template_name` is specified.
>
> The affected views are:
>
> 1. `django.views.defaults.page_not_found`
> 2. `django.views.defaults.server_error`
> 3. `django.views.defaults.bad_request`
> 4. `django.views.defaults.permission_denied`
>
> Note that the views were identified during a preliminary search and it's
> possible this pattern is used elsewhere in the Django code base.
>
> We should consider deprecating this behavior instead of simply turning
> it on since it's slightly backward incompatible.
>
> Thanks to Raphael Michel at #DUTH for helping identifying this issue.
New description:
Default error views attempt to load a template from a default name and
fallback to a string value if a `TemplateDoesNotExist` error is raised in
the process.
This behavior should be altered to actually raise the error if a custom
`template_name` is specified.
The affected views are:
1. `django.views.defaults.page_not_found`
2. `django.views.defaults.server_error`
3. `django.views.defaults.bad_request`
4. `django.views.defaults.permission_denied`
Note that the views were identified during a preliminary search and it's
possible this pattern is used elsewhere in the Django code base.
We should consider deprecating this behavior instead of simply turning it
on since it's slightly backward incompatible.
Thanks to Raphael Michel at #DUTH for helping identifying this issue.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25697#comment:1>
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/067.565c294b6007e3fa7b731b816a4c0fc4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
