Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
only, exclude, and fields #183
I've recently experimented with 'only' to be used as GET query parameter for REST API and went as far as making a PR where exclude's set difference is still applied to only in '_update_fields'.
However, this turned out to bring even more issues regarding attaching REST with marshmallow. If I specify non-existing attribute to only, schema.dump will raise AttributeError. The common python sense would dictate that I should catch the error here and return 404 response for including non-existing attribute.
The problem is if excluded attribute is requested as fields, it will not throw any error and will just exclude those attributes from the response, resulting in an inconsistency and possibly vulnerability in API.
That's why I was thinking maybe fields option should define the boundary of the only using set intersection. This sort of makes exclude redundant, though.
Sorry about the ambiguity.
I was referring to only, exclude, and fields from Meta options.
class MySchema(Schema): class Meta: fields=("foo",) sch = MySchema(only=("baz",)) sch.dump(dict(foo=42)) # attribute error
My assumption was that, and it might be wrong, 'fields' option should set a scope for which fields can be serialized; otherwise it serves little purpose if 'only' option gets to decide. As of now, 'fields' option is only useful for setting default fields.
fields = request.args.get("fields") sch = MySchema(only=fields) user = User.query.get(user_id) sch.dump(user)
client can include any ridiculous field, raising AttributeError.
+1... it is not obvious that 'only' will try to access any attribute on the object given to it. The only and exclude should be limited to the fields list.
Taking it further with above example, someone malicious could get access to any of the objects fields if the developer was not careful to validate the field requested:
Sorry for taking so long to respond to this.
I agree that
What is the desired behavior if passing a field name to