enhancement!: validate input in content API create and update controllers

[innerdvations]

What does it do?

• coreController create and update methods call validateInput()
• validateInput now throws on fields that don't exist on schema
• fixes bug in validateInput where only the first traversal method was being called

Why is it needed?

To make it easier to debug content API create and update requests; we should not be silently removing anything from the users input data.

How to test it?

API tests have been added

To test manually, create a content type and try sending various types of bad input to it (create and update endpoints), and you should receive a 400 bad request instead of a 200/201 success.

Related issue(s)/PR(s)

DX-1136

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
contributor-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 2, 2024 8:46am

[Boegie19]

Could you give an example of 1?

Sure
Lets say I have a custom docuementServiceMiddleware.
Lets now say I have a soft delete plugin like https://github.com/ChristopheCVB/strapi-plugin-soft-delete
And I want to give a variable in the query to softdelete documentService middleware to see soft-deleted rows. so like
SeeDeletedEnteries=True or SeeDeletedEnteries=False

The way we currently do this with the entity-service is with adding an new variable to the ctx.query what is not filters, fields or populate

[innerdvations]

Ahh, ok! For document service itself, I believe it either already has, or plans to have the ability to extend that context, but maybe @Marc-Roig can give more information on that.

[innerdvations]

Adding don't merge label for now until I can be sure we won't be breaking a lot more things than expected by preventing unrecognized attributes.

[Boegie19]

Adding don't merge label for now until I can be sure we won't be breaking a lot more things than expected by preventing unrecognized attributes.

Removing unrecognized attributes should be fine as long as it is only done in fields, populate and filters only. this is fine since currently we already remove them in the controler when we senatize them the only diffrence would be we trow an error now while before it was done silently.

[Marc-Roig]

Any middleware can extend the context in itself, in this case I would extend the context.params which is the one that includes, fields, filters, ...

[Bassel17]

QAed!
LGTM