Email format not properly validated
See original GitHub issuefrom jsonschema import Draft4Validator, FormatChecker
validator = Draft4Validator({'type': 'string', 'format': 'email'}, format_checker=FormatChecker())
validator.validate('test@example.com ')
The above code doesn’t raise an error, but should, at least as far as I understand RFC 5322.
Upon further investigation, your email checking function is terrible. I’ve been trusting this library to handle the hard parts of validation for me (particularly emails!), but even a regex would have been a better way to validate emails. Just for instance, this passes validation:
validator.validate('#@%^%#$@#$@#')
I’d really like to see the email validator pass this suite of tests.
It’s fair that you haven’t implemented the validation, since the jsonschema spec doesn’t require format validation, but partway implementing it, and not warning users (either through raising errors on schemas relying on incompletely-implemented formats, or through documentation), that your format checker doesn’t actually validate against the RFC, is pretty bad. My trust in this library has been shaken, and I’ll be auditing my code to add custom validation logic where necessary, or switching away entirely.
Issue Analytics
- State:
- Created 5 years ago
- Comments:11 (9 by maintainers)
So, for a concrete resolution here I’m going to close this one, but @staab I’ve opened #407 to track the possible change in behavior going forward.
Appreciated!
@staab part of the recent spec work has involved classifying keywords into assertions (which produce a boolean output) annotations (which attach some data in some way that an application can use), and applicators (which apply subschema(s) and combine or modify their results in some way (e.g.
not
is an applicator that inverts its subschemas result,properties
is an applicator that applies based on matching property names, etc.)format
is really more of an annotation, but since it’s purpose is related to validation it’s also kind of an optional assertion. But it’s not a full-fledged assertion keyword. It’s an annotation with a recommended default behavior. Applications can then do further validation, such as sending a test email to the address, whether the validator did any of its own validation or not (I think we can all agree that that would not be a good thing for a validator to do automatically).The hybrid behavior is a little weird, and I’m hoping that by clarifying that framework it’s a little more obvious when the spec is read that the keywords behave a bit differently.