Support for ignoring extraneous fields in rest request body#1608
Support for ignoring extraneous fields in rest request body#1608
Conversation
…://github.com/Azure/data-api-builder into dev/agarwalayush/strictModeForRestRequestBody
seantleonard
left a comment
There was a problem hiding this comment.
last nits but otherwise lgtm! (can approve once Ani's feedback addressed)
Aniruddh25
left a comment
There was a problem hiding this comment.
Last question: why cant we set Default=CliBoolean.True instead of introducing CliBoolean.None?
We can assign a default value of CliBoolean.True instead of CliBoolean.None. But this would unnecessarily log a warning for cosmosdb_nosql during config generation - that cosmosdb does not support REST. When the default value is CliBoolean.None, we would not be logging this warning because we would know that since the value is CliBoolean.None, the option was not included in the init command. We cannot say the same when the default value is kept as CliBoolean.True. We won’t know that this true value is because of default behavior or because the option was included in the command. This might be the case that we would be unnecessarily logging a warning for cosmosdb_nosql even when the user did not include the rest.request-body-strict option. |
seantleonard
left a comment
There was a problem hiding this comment.
last two questions about tests
…://github.com/Azure/data-api-builder into dev/agarwalayush/strictModeForRestRequestBody
Aniruddh25
left a comment
There was a problem hiding this comment.
LGTM after resolving comments! Thanks for your patience on this PR and ensuring new issues found are handled appropriately, and consistently.
Why make this change?
Add support for allowing extraneous fields in request body as per: #1606.
What is this change?
DAB will expose another CLI option in the
initcommandrest.request-body-strict, which when set to true/false, would set the propertyruntime.rest.request-body-strictastrue/falsein the generated runtime config file. What this essentially means is that, as part of the REST mutations (POST/PUT/PATCH), there can be extraneous fields present in the request body and they will be ignored. Default behavior of DAB will continue to be the same as what it is today, i.e. any extraneous fields in the request body would return an error. So to say, the default value ofruntime.rest.request-body-strictistrue.Additional change
Refactored
RequestValidator.csclass to be a singleton dependent onISqlMetaDataProviderandRuntimeConfigProviderservices. Better presents its dependency on the two services and simplifies the code.What are the different extraneous fields?
-> Read-only field are: Computed (or Generated) / AutoGenerated fields in MsSql/MySql/PgSql
-> timestamp fields in MsSql
Questions:
1. What about authorization of extraneous fields?
When operating in flexible mode, the user is not authorized for extraneous fields NOT defined on table because those fields are ignored. For all other cases, authorization goes as usual.
How was this tested?
{*}RestBodyNonStrictModeTests.csclasses inheriting from the base classRestBodyNonStrictModeTests.cs. (* = MsSql,MySql,PostgreSql)rest.request-body-strictfeature in the init command.