Breeze.js — защита вызовов IQueryable

Я бы не стал раскрывать какие-либо данные через IQueryable, которые не должны быть отправлены клиенту через случайный запрос. Таким образом, проекция может быть раскрыта или DTO.

Я не уверен, что это отвечает на ваш вопрос, хотя ... Какие «угрозы безопасности» вас беспокоят?

Я тоже поддерживаю этот вопрос. Но добавим некоторые детали к вопросам, которые задавал Уорд:

При защите запрашиваемых сервисов на ум приходят две традиционные проблемы:

1) Вертикальная безопасность: какие элементы пользователь, вошедший в систему в данный момент (на основе удостоверения пользователя или ролей), НЕ может видеть в пользовательском интерфейсе. Их необходимо удалить из запрашиваемого списка. IMO, это можно сделать как часть запрашиваемой магии ActionFilter, связав некоторую логику исключения в возвращаемом IQueryable. 2) Горизонтальная безопасность: некоторые модели содержат поля, которые не подходят для просмотра (и/или редактирования) вошедшим в систему пользователем. С этим сложнее справиться, поскольку речь идет не просто об удалении экземпляров из возвращенного IQueryable. Возвращаемый класс имеет другую форму и, следовательно, может обрабатываться либо средством форматирования json, опускающим поля на основе безопасности (что AFAIK испортит метаданные бриза), либо вы возвращаете DTO, и в этом случае, поскольку DTO не существует в метаданных это не полный жизненный цикл (обновляемый) класс? (это я не утверждаю)

Хотелось бы видеть либо встроенную поддержку, либо простые в реализации рецепты под номером 2). Возможно, какой-нибудь пример кода для изменения метаданных на стороне клиента, чтобы DTO отлично работали в сочетании с объектами модели. Шаблоны SPA новостей VS 2012 (в приложении TodoList), похоже, подталкивают варианты DTO объекта модели как на запрашиваемой стороне, так и на стороне вставки/обновления. Это похоже на традиционные представления моделей MVC...

Наконец, я бы добавил запрос на автоматическую обработку проблемы безопасности с оверпостингом для вставок и обновлений. Это обратный аспект 2). Некоторые пользователи не должны иметь возможность редактировать определенные поля.