Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate arbitrary exceptions in deserialization #233

Closed
wyfo opened this issue Oct 31, 2021 · 1 comment · Fixed by #244
Closed

Deprecate arbitrary exceptions in deserialization #233

wyfo opened this issue Oct 31, 2021 · 1 comment · Fixed by #244
Labels
breaking change Breaking change in the API deprecation Need to stop this
Milestone

Comments

@wyfo
Copy link
Owner

wyfo commented Oct 31, 2021

Currently, validators/constructors/converters can raise arbitrary exceptions, which are then converted to ValidationError.
This is a security concern, as it could leak implementation details if unwanted exceptions are not properly catched — let's imagine a validator using database, and leaking connection information if this one is temporarily unreachable. This behavior must be deprecated.

Deprecation should also act as breaking change, with a simple way to get back the old behavior, for example a settings key with a deprecation warning.

However, raising a ValidationError is not convenient today, because it's constructor doesn't accept a simple error message string. Constructor should therefore be overloaded.

Also, validators could take a new parameter describing exceptions allowed to be raised in the validator, which would be then converted to ValidationError.

@wyfo wyfo self-assigned this Oct 31, 2021
@wyfo wyfo added breaking change Breaking change in the API deprecation Need to stop this labels Oct 31, 2021
@wyfo wyfo removed their assignment Oct 31, 2021
@wyfo wyfo added this to the v0.17 milestone Nov 2, 2021
@wyfo
Copy link
Owner Author

wyfo commented Nov 11, 2021

Deprecation should also act as breaking change, with a simple way to get back the old behavior, for example a settings key with a deprecation warning.

Finally, no simple way has been added, this is a complete breaking change.

Also, validators could take a new parameter describing exceptions allowed to be raised in the validator, which would be then converted to ValidationError.

As written in the documentation, this completely useless, because a simple decorator can do the job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Breaking change in the API deprecation Need to stop this
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant