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

Support for disallow_unknown_properties option #33

Merged
merged 1 commit into from
Nov 27, 2012

Conversation

nicolaiarocci
Copy link
Contributor

Support for disallow_unknown_properties option, available both in the validate method and in the SchemaValidator contstructor. Set to True to prevent injection of unwanted property/value pairs in your document. Defaults to False.

While you can achieve similar results by setting 'additionalProperties = False', that only works for 'object' types and not for the 'array' type. When an array's 'items' property is set to a schema, it will accept any number of incoming dicts (objects) making sure that known fields match the schema, but still allowing for unknown/unmatched fields (the 'additionalItems' property will only block multiple array items).

Look at the test_disallow_unknown_properties.py module for usage examples.

PS: as an alternative (more verbose, perhaps more coherent) solution would be to provide an array property that does what 'additionalProperty = False' does for 'object' types. Since 'additionalItems' does something else already, maybe something like 'allowUnknownProperties'...

… validate method and in the SchemaValidator contstructor. Set to True to prevent injection of unwanted property/value pairs in your document. Defaults to False.

While you can achieve similar results by setting 'additionalProperties = False', that only works for 'object' types and not for the 'array' type. When an array's 'items' property is set to a schema, it will accept any number of incoming dicts (objects) making sure that known fields match the schema, but still allowing for unknown/unmatched fields (the 'additionalItems' property will only block multiple array items).
@nicolaiarocci
Copy link
Contributor Author

As I said in the original PR, additionalProperties=False works for object types, but there's no corresponding functionality for arrays. I know about additionalItems=False, but that will only prevent additional items in the list It won't stop from inserting unknown fields in each array item definition.

take the following schema definition:

    self.schema_complex = {
        "type": "object",
        "additionalProperties": False,
        "properties": {
            "inv_number": {"type": "string"},
            "rows": {
                "type": "array",
                "items": {
                    "sku": {"type": "string"},
                    "desc": {"type": "string"},
                    "price": {"type": "number"},
                },
            },
        },
    }

I don't want a row like this one:

    newrow = {"sku": "789", "desc": "catch me if you can", "price": 1, "rice": 666}

to be validated (the 'rice' field is unknown). If I set additionalItems=False on the 'rows' array it will prevent addition of multiple items, which is not the desired behavior in this case. I'm probably missing something here.

However what this patch does is preventing unknown fields (both in the main object and in the nested array in this case) to be validated. Maybe there's a better, different way to achieve this (see my PS note on the original PR comment).

jamesturk added a commit that referenced this pull request Nov 27, 2012
Support for disallow_unknown_properties option
@jamesturk jamesturk merged commit f47cfa4 into jpmckinney:master Nov 27, 2012
@jamesturk
Copy link
Collaborator

again, sorry about the delay here- wasn't getting the notifications for this project somehow. I thought this over in more detail and went ahead and merged it, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants