Pass exception to ERROR_PAGE_TEMPLATE after catching TemplateDoesNotExist.

[Rico Rodriguez]

Let's take the example of django.views.defaults.permission_denied, which reads as such:

@requires_csrf_token
def permission_denied(request, exception, template_name=ERROR_403_TEMPLATE_NAME):
    """
    Permission denied (403) handler.

    Templates: :template:`403.html`
    Context: None

    If the template does not exist, an Http403 response containing the text
    "403 Forbidden" (as per RFC 7231) will be returned.
    """
    try:
        template = loader.get_template(template_name)
    except TemplateDoesNotExist:
        if template_name != ERROR_403_TEMPLATE_NAME:
            # Reraise if it's a missing custom template.
            raise
        return HttpResponseForbidden(
            ERROR_PAGE_TEMPLATE % {'title': '403 Forbidden', 'details': ''},
            content_type='text/html',
        )
    return HttpResponseForbidden(
        template.render(request=request, context={'exception': str(exception)})
    )

In the case where I raise something like PermissionDenied("Some message"), it would be nice if "Some message" got passed into ERROR_PAGE_TEMPLATE as the 'details'.

You can see that pretty much every other default view (with the exception of page_not_found, which already passes something in "details") would stand to improve from a similar change.

[Mariusz Felisiak]

In the case where I raise something like PermissionDenied("Some message"), it would be nice if "Some message" got passed into ERROR_PAGE_TEMPLATE as the 'details'.

The current default behavior is ​documented and we cannot change it due to security concerns, see ​discussion. Moreover exception is already passed to a template (after #24733) if you will provide a custom 403.html.

[Rico Rodriguez]

@felixmm It doesn't look like the discussion ended with any firm conclusion that this is indeed any more of a security hole than would be introduced by a developer-provided 403.html template. As Claude mentions in the description of his original patch,

If we exclude 400 errors (500 errors are already excluded in my patch), that leaves 403/404 codes where we should be safe with regard to error messages. And then, Django will not print anything by default, the user still has to provide a custom template containing the expression [sic] context variable.

Correct me if I'm wrong, but it seems that (for 403s at least) this "extra layer of protection" forcing the developer to create a custom 403 template isn't really doing much in the way of providing security. As SuspiciousOperation errors are mapped to 400s, you shouldn't really have to worry about that if the default handler for Bad Requests isn't modified. If I submit a patch, it'd be just modifying the default 403 handler. Does this make sense, or am I missing something?

[Mariusz Felisiak]

Please ​follow triaging guidelines with regards to wontfix tickets. Per my understanding, conclusion from this ​discussion was implemented in #24733. You can always refresh the ​discussion on DevelopersMailingList if you don't agree.

Correct me if I'm wrong, but it seems that (for 403s at least) this "extra layer of protection" forcing the developer to create a custom 403 template isn't really doing much in the way of providing security.

It creates an extra protection because we will not pass messages to users if you don't do it on purpose. Personally, I don't see a big issue in creating a custom template.