Handling authZ for READ operation with no fields referenced in url

[ayush3797]

Why make this change?

Fixes #487.

Context:
This fix takes care of one special case where let's say we have a entity Book in which the READ operation has no column exposed i.e. include = [], or more generally when no field is exposed for READ operation on the entity.
In such a case, when the DAB engine receives a READ request where the url does not contain any key and there are no other clauses like order by/select/filter etc. (eg. the url is https://localhost:5001/api/Book/), all the authorization checks would pass. This is the only case when we would hit the code block in question in this issue here. This however is an invalid case, where the user is not authorized to access any field for the READ operation on the entity and should be failed at the authorization stage itself. The changes in the PR do exactly that.

What is this change?

1. Removed incorrect code block here.
   What the code block used to do?
   In case when the Columns.Count == 0 (where Columns is the list of columns which the query selects), this code block used to add all the fields present in the Entity to the Columns list, which should not be done because if the Columns.Count ==0 at that stage, the user is not authorised to access any field in the entity for the READ operation.
   We should fail such a request in the authorization stage itself.
2. To fail the request in authorization stage, adding additional during column authorization check for READ operation : When OperationMetaData.AllowedExposedColumns.Count() ==0 => The user is not authorized to access any field in the entity for this operation. We thus fail the request.

Example Request to see the issue:

1. Set permission for an READ operation entity lets say Book to have no columns exposed.
2. Execute a GET request with url : https://localhost:5001/api/Book/. It would return all the rows in the books table with all the fields. However since no fields were exposed, the user was not authorized to see any of them, and hence the behavior is incorrect.

[jarupatj]

Do we have a test for this?

[seantleonard]

While the link to the separate issue is good, it would be beneficial to give brief summary here to reduce the need cross reference across issue/PR what is done here.

I don't follow this, can you describe behavior before/after this change and list some sample requests?

Adding additional during column authorization check for READ operation : When OperationMetaData.AllowedExposedColumns.Count() ==0 => The user is not authorized to access any field in the entity for this operation. We fail such a request.

It would be helpful to provide context, especially for other reviewers about why the removed code block was redundant/what that code block was:

Removed redundant code block.

[ayush3797]

While the link to the separate issue is good, it would be beneficial to give brief summary here to reduce the need cross reference across issue/PR what is done here.

I don't follow this, can you describe behavior before/after this change and list some sample requests?

Adding additional during column authorization check for READ operation : When OperationMetaData.AllowedExposedColumns.Count() ==0 => The user is not authorized to access any field in the entity for this operation. We fail such a request.

It would be helpful to provide context, especially for other reviewers about why the removed code block was redundant/what that code block was:

Removed redundant code block.

Addressed your concerns in the PR description. Please have a look.

[ayush3797]

Do we have a test for this?

Yep, in progress.

[Aniruddh25]

LGTM

[severussundar]

LGTM!