Где я должен генерировать токены формы CSRF и CAPTCHA в приложении MVC?

Question

Дано:

Я создал Hash и Captcha классы.Hash создает токены формы.Captcha использует класс Graphics для создания изображения.Пользовательский класс-оболочка службы сеанса используется для обработки суперглобальной структуры данных $_SESSION.

Сценарий:

Я использую контейнер внедрения зависимости.Поэтому я хочу знать, где определить создание экземпляров Captcha и Hash для общедоступных HTML-форм.

Гипотеза 1: Вы должны ввести Hash и Captchaв дочерний элемент Model, поскольку для доступа к $_SESSION требуется хранить (по HTTP-запросу) и проверять (при HTTP-ответе) токены CSRF и ответы CAPTCHA.Представление никогда не должно обращаться к структурам данных сеанса.

Гипотеза 2: Вы должны внедрить Hash и Captcha в дочерний элемент View, поскольку генерация токенов CSRF и CAPTCHA фактически является частьюлогики представления представления , даже если проверка их происходит в Model.Доступ к структурам данных сеанса, прямо или косвенно, из View разрешен.

Гипотеза номер один кажется ответом, но я хочу быть уверенным.

Абстрактный пример:

$session = new Session(); // A custom wrapper class
$hash = new Hash();
$graphics = new Graphics();
$captcha = new Captcha($graphics);


$model = new ContactModel($session, $hash, $captcha);

или

$view = new ContactView($session, $hash, $captcha);

Answer 1

Ответ : Вы должны сгенерировать токены CSRF и значения CAPTCHA в «Модели».

Причина : Цель этих значений - служить ограничениемна вашей бизнес-логике, а не просто отображать значения или элементы управления в «представлении».Если бы «Просмотр» сгенерировал токены формы и значения запроса CAPTCHA, он должен был бы сообщить их обратно «Модели» (так или иначе).Это идет вразрез с потоком.

Хотя гипотеза номер два осуществима, она возлагает обязанности на Вид, который он не завершает полностью.В частности, представление никогда не будет отвечать за проверку токенов формы или ответов CAPTCHA.

Представление может, как в манекене, вставлять токены формы и вызовы CAPTCHA в шаблон формы HTML (например).Это правда, однако теперь «представление» будет отвечать за сохранение ответов в каком-либо постоянном хранилище, в то время как «модель» будет только извлекать и проверять их.

Таким образом, хранилище сеанса будет действовать как обратный канал между «Видом» и «Моделью» и, следовательно, , связывающий их (даже если используется какая-то оболочка службы сеанса).«Представление» не должно передавать данные в «Модель», но именно это и происходит, если «Представлению» разрешено генерировать токены формы и значения ответов CAPTCHA.

Этомой ответЯ приветствую ваши комментарии и критику.

Answer 2

_{Примечание № 1: Я думаю, вам следует прочитать этот пост .Я выделю основную часть этого ответа: «Модель не является классом или каким-либо отдельным объектом»}

_{Примечание № 2: ИМО, эта проблема присуща веб-реализациям MVC.Первая часть о том, как бы я решил эту проблему;следующее концептуально описывает, почему существует эта проблема.}

Мой ответ: нет .

Архитектура MVC разделенав 2 слоя: слой модель и слой презентация .Служебный объект (он находится на уровне модели) должен создавать / сохранять соответствующую информацию капчи в состояние клиента.Поскольку это, скорее всего, веб-приложение, уровень представления, в частности объект представления, должен будет запрашивать это состояние клиента у уровня модели.Происходит ли это через объект службы или объект доступа к данным для конкретной презентации, специально предназначенный для ответов состояния клиента, зависит от вашей реализации и наилучшего соответствия.Именно здесь, в представлении, я бы сохранял состояние клиента в сеансе через другой объект доступа к данным или (Cookie/Session)Response абстракцию *.Таким образом, представление не «обращается» к структуре данных сеанса, а использует компонент (DAO уровня представления или (Cookie/Session)Response абстракция *) для выполнения этой работы.Хотя мы не рассматриваем файлы cookie / сеансы как презентацию ( «они не визуальные» ), уровень представления отвечает за ответы, и файлы cookie / сеансы - это не что иное, как

* 1034.* Мне трудно рассуждать, как это будет происходить в вашей среде, так как, похоже, существует смешение уровня модели.Ваш ContactModel наверняка захочет, чтобы хэш / капча спасли состояние клиента.Вашему представлению не понадобится ни один из них, но дополнительный механизм для «ответа» состояния клиента на HTTP-запрос в форме файла cookie / сеанса.

_{* Обычно Symfony полезен дляэтот.Я использую как DAO уровня представления, так и объект Symfony HttpFoundation, который может быть за бортом.}

Концептуально: сеансы как состояние против ответа

Фундаментальная проблемаздесь вы работаете с конкретными реализациями веб-MVC.Уровень представления в веб-MVC обрабатывает «запрос» (делегированный контроллеру) и представляет «ответ» (определяется представлением).В HTTP файлы cookie и сеансы отправляются с запросами и изменяются в ответах.Это встроено в природу HTTP-запроса / ответа.

Если мы поместим сохранение сеанса / cookie-файла на уровень модели, мы сделаем наш уровень модели зависимым от HTTP и разрешим ему «отвечать» на запросы.Даже если мы абстрагируем суперглобальные переменные и «внедряем» абстракции (например, объекты cookie / сессии Symfony), существует внутренняя зависимость от файлов cookie / сеансов, которые являются реализациями запросов / ответов.Вы можете делать все это на уровне модели, но я предпочитаю этого не делать.Другими словами, хотя модель отвечает за отслеживание состояний , состояние cookie / сеанса на самом деле является ответом на запрос.

"Но это утечка логики, посколькувы сохраняете состояние в слое презентации "

Я думаю, что вы можете рассматривать все методы как" утечки ", и это только самый связный способ.Конечно, мы «сохраняем» состояние на уровне представления, если вы смотрите на cookie / session как состояние.Если вы посмотрите на них как на ответ, которым они действительно являются в глазах MVC, то это вовсе не утечка.Я бы сказал, что отправка ответа (сохранение состояния сеанса / файла cookie) на уровне модели хуже.