Upgrade validation logic #275
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This ports the validation logic from `protovalidate-go` for validating URIs and URI references. As a result, all conformance tests for 0.10.3 related to these validations are now passing. This uses a single underscore for protected class members and a double-underscore for private class methods to use name-mangling. There are varying recommendations on how to structure these (for example, Effective Python recommends public members, some recommendations suggest a single-underscore for class methods, etc.). The current pattern in protovalidate-python seems to use a single underscore for module-level functions, which we could certainly adopt for classes. I'm open to whatever is the established pattern that we should adopt.
Here is a proposal for how to structure docstrings in protovalidate-python going forward (at least when porting the rest of the validation implementations). I think this strikes the right balance of adhering to best practices while not being onerous. * Functions being added to the library should get the bulk of the comment description in a docstring. No need to define `Args:`, `Raises:`, etc. though. * Any other public function, class, etc. should preferably have docstrings, though not necessary. * Be as succinct as possible while also keeping comments across implementations consistently worded. For validation following an RFC / spec: * Always include any relevant ABNF grammar and keep aligned. * Indent grammar inside docstring. One suggestion outside the scope of this PR might be to always have full docstring (`Args`, `Raises`, etc.) on any public method the user interacts with (i.e. stuff in `validator.py`)
This beefs up the validation for the following: IP address (v4 and v6) IP prefix (v4 and v6) Hostname / Port The validation here adheres to the defined RFC standards for each entity and passes conformance for all new conformance tests defined in bufbuild/protovalidate#320.
- Avoid ambiguity in "string contains" - Don't quote identifiers with backticks - KISS with "Parses the rule" Context: bufbuild/protovalidate-java#257 (comment) Also see: bufbuild/protovalidate-go#208
This ports the ipv6 fix from bufbuild/protovalidate-go#215. For context see the description on the above PR. The summary is that this fixes the validation for some corner cases of IPv6 address validation. Namely: * Adds a check that an IPv6 address can't begin or end on a single colon. * Adds a check to fail-fast on invalid hextets.
pkwarren
approved these changes
Apr 14, 2025
Co-authored-by: Philip K. Warren <pkwarren@users.noreply.github.com>
pkwarren
approved these changes
Apr 14, 2025
Update generated code to match runtime requirement (6.30.1). Make some small fixes to custom CEL functions.
pkwarren
approved these changes
Apr 15, 2025
|
Looks good to me, but please give me a bit of time to do some fuzzing on this branch before we merge it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This includes upgrades to validation logic for:
The validation here adheres to the defined RFC standards for each entity and passes conformance for all new conformance tests defined in: