Pass exception to error handlers

[Claude Paroz]

The request to pass the exception to error handlers has been won't-fixed in tickets #20156 / #20803.
I'd like to reopen the discussion. While the usefulness for 404 errors are indeed questionable, I think it makes sense to provide some context to most error chains through the exception. Typically a message explaining why the access to an object is refused (403). I don't see why Django should prevent such use cases. The discussion is open :-)

Claude

[Claude Paroz]

Here is some code to demonstrate a possible implementation:
https://github.com/claudep/django/commit/5617d32e8f10861fb84bf26297dfcd4e4e40d6d7

[florent...@u-dox.com]

I find this interesting too. It could be very useful when using custom exception in the model.

[Tim Graham]

I have some concerns from a security standpoint. For example, some exception messages are definitely not meant to be displayed to end users and may leak server implementation details. For example:

SuspiciousFileOperation(
    'The joined path ({}) is located outside of the base path '
    'component ({})'.format(final_path, base_path)
)

If we proceed with the idea, maybe a separate exception attribute for a "user facing message" would be appropriate. Of course, if we pass the raw exception to the error handlers, we cannot prevent programmers from writing str(exception) (instead of using that custom attribute) and writing insecure code. As to whether that concern should block this feature, I'm not sure.

[Claude Paroz]

Le mercredi 22 avril 2015 à 07:05 -0700, Tim Graham a écrit :
> I have some concerns from a security standpoint. For example, some
> exception messages are definitely not meant to be displayed to end
> users and may leak server implementation details. For example:
>
> SuspiciousFileOperation(
> 'The joined path ({}) is located outside of the base path '
> 'component ({})'.format(final_path, base_path)
> )

That makes sense. But as SuspiciousOperation is special-cased in
get_response, we can as well pass None in the exception parameter. It's
not the typical situation where we want the user to receive a specific
message.

> If we proceed with the idea, maybe a separate exception attribute for
> a "user facing message" would be appropriate. Of course, if we pass
> the raw exception to the error handlers, we cannot prevent programmers
> from writing str(exception) (instead of using that custom attribute)
> and writing insecure code. As to whether that concern should block
> this feature, I'm not sure.

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`
context variable.

Claude

[Tom Evans]

On Wed, Apr 22, 2015 at 3:05 PM, Tim Graham <timog...@gmail.com> wrote:
> I have some concerns from a security standpoint. For example, some exception
> messages are definitely not meant to be displayed to end users and may leak
> server implementation details. For example:

This is saying you can't have a gun because you might shoot yourself
in the foot, but then how do you shoot the bear?

The error handler is under the developers control, so what they choose
to do with the exception is their business. The default implementation
need not show anything more than is currently available, but it could
be replaced with something that does what the developer needs, and it
would be their responsibility that they keep their toes, so to speak.

Cheers

Tom

[Florent Pastor]

I agree with Tom

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/kcFqjmnlUTQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFHbX1J-uiNoP9OuHqX3ekPj77k%3DmbEbWsevRnakmYevBQu5EQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Claude Paroz]

New ticket created: https://code.djangoproject.com/ticket/24733

Claude