3

私はODataが好きで、ASP.NETWebAPIによる採用に特に満足しています。

内部アプリケーションが使用するためのサービスをいくつか作成しましたが、公開用には作成していません。主な理由は、ODataのオープンな性質により、悪用に対して「安全」にすることが非常に困難になっているように見えることです。

具体的には、任意のクエリを実行する能力があれば、ユーザーが複雑なクエリを表現して、他のすべてのユーザーのエクスペリエンスが悪くなるまで運用システムに負荷をかける可能性があるのではないかと心配しています。

WebApiコントローラーでは、ODataエンドポイントは次のように公開されます。

public class OrderController
{
    [Queryable]
    public IQueryable<Orders> Get()
    {
         // Compose and return the IQueryable<Orders>
    }
}

これにより、クエリの作成と実行のプロセスを完全に制御できますが、複雑なIQuerable<T>インターフェイスを介して制御できます。ユーザーに情報のサブセットを提供するのは簡単です。たとえば、Whereアクセス許可のあるレコードのみを含めるようにaを追加します。

IQueryable<T>既存のIQuerable<T>インスタンスをラップして、ユーザーが実行できるクエリに制限を設けることができる実装はありますか？クエリの複雑さを制限することに最も関心がありますが、ユーザーがアクセスできないはずのリソースへの関連付けをトラバースしないようにすることもできます。

4

2 に答える 2

3

RTMには、ユーザーに公開するクエリの種類をカスタマイズできるオプションが追加されていることを知っていただければ幸いです。したがって、たとえばこれを行うことができます。

[Queryable(
    AllowedFunctions = AllowedFunctions.AllStringFunctions,
    AllowedLogicalOperators = AllowedLogicalOperators.Equal,
    AllowedOrderByProperties = "ID")]

いくつかの一般的な方法でクエリを制限します。クエリをさらに制限したい場合は、属性のメソッドをODataQueryValidatorオーバーライドするなどして、プラグインできる検証フックがあります。ValidateQuery[Queryable]

ナイトリービルドを使用してこれらの機能にアクセスしたり、最新のビットを自分でビルドしたりできます。

于 2013-01-14T19:11:36.193 に答える
2

Queryable 属性 (欠落している) を使用する代わりに、この属性を使用できず、代わりに ODataQueryOptions パラメーターを手動で受け入れます。これにより、さまざまなフィルター、トップなどのオプションにアクセスして、それらの検証を許可できます。

OData クエリによって呼び出される関数には、次のような引数 ODataQueryOptions を渡すことができます。

public IQueryable<T> Get(ODataQueryOptions options)`  
{ 
//Use the following vars to fetch the values, and check if
//they are as you expect them to be. etc.  
options.Top.RawValue;
options.Filter.Value;
options.Filter.ApplyTo();
}

この場合、 [Queryable] 属性をスキップApplyToして、結果にさまざまなクエリを手動で適用するために使用できます。:)

于 2013-01-14T16:49:42.750 に答える