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.
On Wednesday, April 22, 2015 at 7:12:53 AM UTC-4, [email protected]
wrote:
>
> I find this interesting too. It could be very useful when using custom
> exception in the model.
>
> On Tuesday, April 21, 2015 at 8:58:59 PM UTC+1, Claude Paroz wrote:
>>
>> Here is some code to demonstrate a possible implementation:
>>
>> https://github.com/claudep/django/commit/5617d32e8f10861fb84bf26297dfcd4e4e40d6d7
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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].
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/25dc9714-64a6-4973-ad99-af73766becd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
