Вопрос по – OData веб-API ASP.Net. Потребители могут свободно запрашивать все, что им хочется?

2

Я только что читал о поддержке ASP.Net Web API для запросов OData, и у меня возникли проблемы с согласованием внешнего воздействия для фильтрации запросов, что, по сути, дает интеграторам возможность создавать любые произвольные фильтры запросов в базе данных, не принимая во внимание оптимальные планы запросов, поля, на которые не следует запрашивать и т. д.

Как можно выполнить санацию запроса OData, чтобы пользователь не мог запускать ужасные сложные запросы непосредственно в базе данных, что может вызвать проблемы с производительностью, и которые могут содержать ссылки на поля, в отношении которых не должно выполняться?

Ваш Ответ

3   ответа
1

На мой взгляд, это архитектурный компромисс использования синтаксиса запроса OData. Если вы не хотите, чтобы у людей был неограниченный доступ к запросу, не используйте его. Это то же самое, аргумент «Представления SQL в сравнении с хранимыми процедурами SQL».

@NathanRidley Конечно, и именно поэтому они предоставляют хранимые процессы вместо неограниченного доступа к запросам. Я говорю, сделайте то же самое с вашим API, выставив ресурсы, которые предварительно жевали. запросы. Добавление новых ресурсов в систему должно быть очень дешевым и простым.
Похоже на странный компромисс, учитывая потенциальную нагрузку, которую плохой запрос может поместить в базу данных. По этой причине администраторы баз данных тратят много времени на разработку эффективных стратегий запросов ... Nathan Ridley
2

мы смотрим на решение этих проблем. Начиная с Web API RC мы требуем, чтобы вы явно аннотировали свой метод[Queryable] чтобы указать, что вы хотите включить режим автоматической фильтрации. Мы также рассматриваем некоторые другие API расширяемости / настройки, которые станут доступны позже.

По сути, поскольку это автоматическая система, от разработчика требуется некоторое понимание всех аспектов производительности и безопасности. В некотором смысле это ничем не отличается от проблемы избыточного размещения в привязке модели параметров (например, кто-то публикует объект User, для свойства IsAdmin которого установлено значение true, даже если ваш API никогда не документировал, что он поддерживает такое свойство. тип модели, который вы используете на сервере, также имеет свойство IsAdmin). Такие проблемы могут быть решены путем написания конкретных объектов DTO, которые жестко контролируют, какие данные вы предоставляете и принимаете в качестве входных данных.

1

Веб-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

Если вы хотите скрыть от пользователя фильтрацию / запрос некоторых столбцов, то одним из способов является написание собственного обработчика, который будет анализировать URI пользователя и возвращать, например, Ошибка 403 или, как вариант, создание объектов DTO без этих столбцов и предоставление их для «предварительного запроса»; пользователю.

Хорошо, кажется, не полностью понимаю. Один из способов - написать собственный обработчик, который будет анализировать URI пользователя и возвращать, например, Ошибка 403 Или, как вариант, сделать объекты DTO без этих столбцов и выставить их для «предварительного запроса»; использовать объекты DTO
Да, но как я могу предотвратить, например, запрос к конкретному столбцу? например$filter=SecureField eq 'foo' Nathan Ridley

Похожие вопросы