ASP.Net Web API OData - Consumers have free reign to query whatever and however they want?

Question

I\'ve just been reading about the ASP.Net Web API support for OData queries and I\'m having trouble reconciling the external exposure for query filtering, which essentially prov

Answer 1

we are looking at addressing these concerns. Starting with Web API RC we require that you explicitly annotate your method with [Queryable] to indicate that you want to opt into the automatic filtering behavior. We are also looking at some other extensibility/customization APIs that will become available later.

Fundamentally since this is an automatic system it requires some understanding on the part of the developer to know all of the performance/security considerations. In a sense it's no different than the issue of overposting in parameter model binding (e.g. someone posts a User object that has the IsAdmin property set to true even though your API never documented that it supports such a property. It happens to work because the model type you use on the server also has a IsAdmin property). Such concerns can be addressed by writing specific DTO objects that tightly control what data you expose and accept as input.

Answer 2

Web API has special handlers mechanism. So you can check and process queries that are going from user.

http://www.asp.net/web-api/overview/working-with-http/http-message-handlers

But for OData queries it's not common to expose IQueryable from database. Common approach is to make general query, "pre-queried" on server and than give user ability to query or filter this prequeried result. And than you will be sure that user wasn't able to make query "wider" than prequeried result.

And as a note: WebAPI has only support for filter, top, skip, orderby. So very limited. For normal OData support - use WCF Data Services

When you want to hide from user filtering/querying some columns, than one way is writing custom handler that will parse URI from user and return e.g. 403 error, or as a variant to make DTOs objects without these columns and expose them for "pre-query" to user.

Answer 3

In my opinion, this is a architectural tradeoff of using the OData query syntax. If you don't want people to have unconstrained query access, don't use it. It's the same, SQL Views versus SQL Stored procedures argument.