Inconsinstent behaviour of query parameters on Entities

[DanielBertocci]

I was investigating on query parameters on entities and I spotted the following behavior:

Assume to have in the database only on Thing with id 1.

Here the following requests:

Method	Request	Response	Expected
GET	Things(2)	404	Yes
GET	Things(1)?$filter=id eq 2	404	Yes
PATCH	Things(2)	404	Yes
PATCH	Things(1)?$filter=id eq 2	404	Yes
DELETE	Things(2)	404	Yes
DELETE	Things(2)?$filter=id eq 2	400 No query options allowed on PATH when deleting an entity	No

The last request is inconsistent with the others. I find the behaviors of GET and PATCH very useful for authorization purposes and I wonder if would be possible to have the same on DELETE.

[hylkevds]

Officially, the inconsistent ones are the GET and PATCH ones with a filter, since $filter should only be allowed for requests to EntitySets, not for requests to individual entities...

Can you explain how you use those for authorization purposes?

[DanielBertocci]

In front of FROST you can have an authorization layer that defines constraints for users using directly the same filter used in frost. I am going to provide a very simplified example that does not cover all use cases.

For example: user A can access only Things about project X. What you can do is that every time user A try to query Things, you send the request to FROST Things?$filter=properties/project eq 'X' (similarly for expansion). The fact that the filter works also for a single entity, allows to avoid to retrieve the entity first and verify manually if it has the properties. For GET requests is not a big difference, but for PATCH and DELETE you avoid an HTTP request.

For more details I can discuss in PM.

[hylkevds]

That is something FROST can do itself, directly in the database, using the fine-grained authorisation options. By having FROST handle the authorisation, it takes all API feature in consideration, including expands, DataArrays and Batch processing.

The Projects Plugin is the default set-up, but you can customise it with any SQL you'd like.

[DanielBertocci]

Thank you for pointing out that page, it is indeed useful for the example I pointed out. It is something that actually I have explored but I had good reasons to keep separate the authorization layer from FROST. It is just a component of a wider solution.

Focusing on the inconsistencies, do you think GET and PATCH won't support that behavior anymore or will DELETE align?