2

OData クエリの ASP.Net Web API サポートについて読んだところですが、クエリ フィルタリングの外部公開を調整するのに苦労しています。最適なクエリ プラン、クエリを実行してはならないフィールドなど。

OData クエリをサニタイズして、パフォーマンスの問題を引き起こす可能性があり、実行されるべきではないフィールドへの参照が含まれている可能性がある、恐ろしく複雑なクエリをデータベースに直接投げることができないようにするにはどうすればよいでしょうか?

4

3 に答える 3

2

私たちはこれらの懸念に対処することを検討しています。Web API RC 以降では、メソッドに明示的にアノテーションを付けて[Queryable]、自動フィルタリング動作を選択することを示す必要があります。また、後で利用可能になる他の拡張性/カスタマイズ API についても検討しています。

基本的に、これは自動システムであるため、パフォーマンス/セキュリティに関するすべての考慮事項を知るには、開発者側である程度の理解が必要です。ある意味では、パラメータ モデル バインディングでのオーバーポスティングの問題と同じです (たとえば、IsAdmin プロパティが true に設定された User オブジェクトを、API がそのようなプロパティをサポートすることを文書化していなくても、誰かが投稿します。モデルがサーバーで使用する型にも IsAdmin プロパティがあります)。このような問題は、どのデータを公開して入力として受け入れるかを厳密に制御する特定の DTO オブジェクトを作成することで対処できます。

于 2012-06-02T18:59:24.370 に答える
1

私の意見では、これはODataクエリ構文を使用することのアーキテクチャ上のトレードオフです。制約のないクエリアクセスを他のユーザーに許可したくない場合は、それを使用しないでください。これは同じです。SQLビューとSQLストアドプロシージャの引数です。

于 2012-06-02T12:21:26.537 に答える
1

Web API には特別なハンドラー メカニズムがあります。したがって、ユーザーからのクエリを確認して処理できます。

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

ただし、OData クエリの場合、データベースから IQueryable を公開することは一般的ではありません。一般的なアプローチは、サーバー上で「事前クエリ」された一般的なクエリを作成し、ユーザーがこの事前クエリされた結果をクエリまたはフィルタリングできるようにすることです。そして、ユーザーがクエリを事前にクエリした結果よりも「広く」することができなかったことを確認してください。

注: WebAPI は、filter、top、skip、orderby のみをサポートしています。とても限られています。通常の OData サポートについては、WCF Data Services を使用してください

いくつかの列をフィルタリング/クエリするユーザーから隠したい場合、1 つの方法は、ユーザーからの URI を解析して 403 エラーなどを返すカスタム ハンドラーを作成することです。または、これらの列を持たない DTO オブジェクトを作成し、"事前クエリ」をユーザーに送信します。

于 2012-06-02T10:17:06.123 に答える