Conditionally whitelist datetime.datetime and add tests #767
Conversation
|
|
||
| p = RestrictedProxyFieldsModel( | ||
| datetime_field=restricted_datetime, # type: ignore | ||
| path_field=restricted_path, # type: ignore |
There was a problem hiding this comment.
The restricted pathlib.Path instance is accepted by pydantic but the restricted datetime.datetime is not:
E pydantic_core._pydantic_core.ValidationError: 1 validation error for RestrictedProxyFieldsModel
E datetime_field
E Input should be a valid datetime [type=datetime_type, input_value=datetime.datetime(2025, 1, 2, 3, 4, 5), input_type=_RestrictedProxy]
E For further information visit https://errors.pydantic.dev/2.10/v/datetime_type
There was a problem hiding this comment.
This seems to be due to the fact that datetime has a custom validation method in Pydantic's Rust layer: https://github.com/pydantic/pydantic-core/blob/741961c05847d9e9ee517cd783e24c2b58e5596b/src/input/input_python.rs#L548-L582
and _RestrictedProxy does not pass the self.downcast::<PyDateTime> test which leads to the validation failure.
UUID does also: https://github.com/pydantic/pydantic-core/blob/741961c05847d9e9ee517cd783e24c2b58e5596b/src/validators/uuid.rs#L95-L154 but _RestrictedProxy does not cause it to fail. And pathlib.Path does not seem to have a dedicated validator in pydantic_core.
a2eb8a9 to
a8a5018
Compare
a8a5018 to
29b79d1
Compare
29b79d1 to
fe6edf2
Compare
| # and uuid.UUID which are likely to be used in Pydantic model fields | ||
| # currently pass Pydantic's validation when wrapped by RestrictedProxy. | ||
| do_not_restrict.append(datetime.date) # e.g. datetime.datetime | ||
| return v is not None and not isinstance(v, tuple(do_not_restrict)) |
There was a problem hiding this comment.
So datetime.datetime will be whitelisted for Pydantic v2 users, but not for v1 users. However, the __get_pydantic_core_schema__ impl doesn't do anything for v1 users, so they have to disable sandboxing of datetime.datetime entirely (e.g. per the sample), so _is_restrictable is irrelevant for them.
There was a problem hiding this comment.
Works for me. Though I know we don't prematurely optimize, I wonder if there are performance concerns for making list, appending to list, and turning to tuple every time this call is made if you also happen to have pydantic v2 in your venv. We always made the tuple before, so maybe it doesn't matter. Could make this tuple global if you wanted, but I'm ok with this.
There was a problem hiding this comment.
Good call, I agree. Performance or not that code looked a bit silly. d915d5b
| # and uuid.UUID which are likely to be used in Pydantic model fields | ||
| # currently pass Pydantic's validation when wrapped by RestrictedProxy. | ||
| do_not_restrict.append(datetime.date) # e.g. datetime.datetime | ||
| return v is not None and not isinstance(v, tuple(do_not_restrict)) |
There was a problem hiding this comment.
Works for me. Though I know we don't prematurely optimize, I wonder if there are performance concerns for making list, appending to list, and turning to tuple every time this call is made if you also happen to have pydantic v2 in your venv. We always made the tuple before, so maybe it doesn't matter. Could make this tuple global if you wanted, but I'm ok with this.
d915d5b to
be66306
Compare
No description provided.