Клиент постит форму. Примитивная валидация (клиентская, затем серверная), то есть проверка диапазонов чисел, длин строк и т.п. - прошла.

Далее надо проверить Id объектов. К примеру, юзер выбирает что-то из списка, причем этот список для него выводится не весь (ограничен его правами или текущим контекстом). Но надо проверить, не подменил ли злоумышленник Id объекта в POST-запросе, чтобы получить недоступный ему элемент. То есть это уровень проверки, затрагивающий DAL в большинстве случаев.

Как вы поступаете в таких случаях? Просто персонально фигачите валидацию для каждой формы? Или есть какие-нибудь типовые приёмы, шаблоны?

ЗЫ: использую EF для доступа к данным

hVosttДругое дело, когда всю валидацию отдают на откуп бизнес-логике, она плюётся исключениями, в контроллере эти исключения отлавливаются, расшифровываются и отправляются клиенту. Это очень плохой, отвратительный сценарий, недопустимый в адекватном проекте. Это наивная и дешёвая попытка сэкономить на кодинге, поэтому сразу советую исключить из рассмотрения подобные подходы с «централизованной валидации».Но уровень контроллер/вью ничего не знает о DAL-е, он делает валидацию только того, что он может сделать без DAL-а, то есть полноценной проверки там нет.

Бизнес-логика делает серьезную проверку с привлечением DAL-а. При этом, ты говоришь о том, что бизнес-логика должна валидировать повторно такие вещи, как, например, допустимая длина строкового поля.

Думаю, тут все-таки есть место для спора о том, зачем тогда валидировать на уровне контроллера/вью? Ок, механизм выплевывания исключений при ошибках валидации я тоже не поддерживаю, но бизнес-модель так или иначе возвращает стандартные ошибки валидации типа "такое название папки уже существует, выберите другое название". Она также может вернуть и ошибку длины строки.

============================================================

Впрочем, мой вопрос был не об этом.

Вот пришли данные в бизнес-слой. Прежде, чем я отдам в DAL набор данных для записи в базу, надо проверить валидность некоторых Id (тех, которые DAL сочтет допустимыми, так как они не нарушат ссылочную целостность, но неприемлемы по бизнес-соображениям и это уровень компетенции бизнес-модели, а не DAL).

Так вот, собственно, может есть какие-то приемы унификации таких проверок.

skyANAО какой валидности речь? :) Права, или что? .... "бизнес-соображения" обычно можно простым человеческим языком описать. Так опишите, не ходите вокруг да около.Права в частности.

Допустим пользователь меняет статус документа. Он может иметь права установить тот или иной статус. Также некоторые статусы не могут устанавливаться для документа, находящегося в определенном состоянии (к примеру, статус "к оплате", если документ имеет признак "удален", или владелец документа не совпадает с текущим пользователем). Другой пример - рядовой сотрудник не может отправить сообщению директору, но может коллеге или непосредственному начальнику.

Хочется уменьшить количество рутинных операций.
Например, использовать процедуру выдачи списка для клиента (в момент создания формы) повторно при валидации данных пришедших с этой же формы.

Я не пытаюсь получить какой-то конкретный ответ на какой-то конкретный вопрос. Скорее, расспрашиваю о приемах, которыми вы пользуетесь.

MonochromatiqueДругой вариант - попроще.

Любой возможный клиенсткий ввод - хешировать. На сервере. С солью.Нет, плохая идея. Как минимум потому, что состояние может устаревать (пока юзер думал надо сменой статуса, кто-то уже удалил документ)

skyANAИ есть SecurityServiceskyANAНо переходы статусов ИМХО не к безопасности (security) относятся, а к validation, или к workflow. К безопасности относится то, может-ли пользователь в принципе изменить статус документа.Ага. Вот и хочется похоже, в каком-то обобщенном виде организовать такие проверки...

ViPRosесли кто то может менять ИД чего то, то он может и ИД клиентас чего вдруг? Пользователь-то авторизован, это проверяется в первую очередь.

Изопропилопять перепутали авторизацию с аутентификацией?виноват, но почему опять? )

тем не менее, авторизация пользователя может быть также выполнена, но недопустимые операции - это все-таки не совсем авторизация )