Personal data query parameter validation

[alapto]

Validate personal data query parameters that can be passed to TSP on read-by-id and options-list requests.

Todos:

• Write tests

Versioning:

• Breaking change

[medikoo]

I think fact that GET query is flat should not affect JSON representation that we validate.

We had similar situation in ontrack and over there @hieuunguyeen used qs to unserialize nested object that came with GET before validation.

That we way we may reuse validation for same nested structures across GET and POST requests.

[alapto]

Otrack querystring validation schema is here https://github.com/maasglobal/maas-schemas/blob/develop/schemas/tsp/journey-planner/request.json#L5-L8

Not really performing proper validation

[medikoo]

I just remember discussing with @hieuunguyeen nesting properties, but didn't look into outcome.

Anyway I think we should just reuse same structures across GET and POST requests, and configure schema only for normal object structures not influenced by limitation of a transport method.

[alapto]

Not dismissing your idea, it could work nicely but requires more effort and in that case I would propose postponing this PR and first merging the TSP changes that we need to get for next release and then apply validation on release after that

[hieuunguyeen]

I also think that schemas should be validating the raw request coming in, regardless of transportation method.
Defining schema with normal object structure hinting that request is required to go through parser before it could be validated.

[medikoo]

I also think that schemas should be validating the raw request coming in,

@hieuunguyeen if we follow this advice, then schema's should validate query strings passed in direct form (so e.g. string "foo=bar&other=etc" should be passed to schema validate).

JSON schemas are purely about JSON objects, and to comply to that, we already do not validate raw request, but parse query string format into JSON before validation. I don't think it should be problematic to improve serialization/deserialization method (we already apply on our ends) so it can also handle nested object structures.

Big downside of what's proposed here is that it forces us to maintain two schemas for exactly same data (once handled in format as { customer: { lastName, firstName } }, and then as { "customer[firstName]" , "customer[lastName]" }.

Design and maintenance wise it looks quite bad to me.