TempData: это безопасно? - PullRequest
       16

TempData: это безопасно?

20 голосов
/ 23 ноября 2011

Я использую TempData, чтобы сохранить мою модель при использовании RedirectToAction.Это работает нормально, но у меня есть ноющее чувство, что это может быть неправильно.Я действительно стараюсь избегать использования данных сеанса, и я прочитал, что TempData использует сеанс.Это безопасно для использования?Существуют ли проблемы, которые могут возникнуть при его использовании в среде с балансировкой нагрузки?

Общая информация: «Безопасно ли это?» - назовите фильм.

Ответы [ 5 ]

22 голосов
/ 23 ноября 2011

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

Относительно того, правильно ли это делать ... зависит от вашего варианта использования!

PSМарафонец.

5 голосов
/ 23 ноября 2011

Ну, я бы сказал, что это зависит.Если вы обрабатываете большой трафик с помощью балансировщиков нагрузки и нескольких серверов переднего плана, то объекты сеанса следует избегать, поскольку это может привести к снижению производительности и затруднить масштабное масштабирование (при запросе фермы не всегда поступает на один и тот же веб-сервер).

TempData недолговечен, и если вы не поместите туда много объектов и дважды подумаете о всей архитектуре, я думаю, тогда это безопасно.Есть много сайтов, которые широко используют его и не имеют проблем с ним (я работал над общими и выделенными хостинговыми сайтами со средним числом посетителей 50-70 тыс. В день, которые используют сеанс, часто с сетью и базой данных на одном сервере).

2 голосов
/ 23 ноября 2011

Состояние сеанса может работать в кластерной среде, при условии, что происходит одно из двух:

  1. Ваш балансировщик нагрузки поддерживает "липкие" сеансы (т.е. все запросы в данном сеансемаршрутизируются на тот же компьютер)
  2. Вы настраиваете поставщика сеансов для использования поставщика сеансов вне процесса, вы можете использовать либо ASP.NET State Service , либо сеанс SQLState Provider

Вопрос о том, следует ли вам использовать временные данные или нет, это совсем другой вопрос.Я бы сказал, что обычно есть способ обойти это.Если вы пытаетесь избежать попадания в базу данных для перезагрузки объекта, который уже загружено одним действием, обратите внимание на использование кеша.

2 голосов
/ 23 ноября 2011

Я бы пошел, когда это возможно, на полностью безгосударственный подход. Он более масштабируемый и не подвержен проблемам с отдельными серверами. Как правило, вы можете просто использовать cookie (должным образом защищенный от взлома), чтобы идентифицировать пользователя и каждый раз извлекать данные из базы данных.

Кроме того, я также предлагаю вам оценить, можете ли вы использовать View вместо RedirectToAction. Это:

TempData["model"] = model;
return RedirectToAction("SomeAction");

Может быть заменено на:

return View("SomeAction", model);

Конечно, предполагая, что «SomeAction» является допустимым представлением, доступным из текущего контроллера (это либо представление в том же ctrl, либо определенное в Shared), и что это не просто промежуточное действие, которое перенаправляет на другое.

1 голос
/ 23 ноября 2011

Я ограничил использование TempData для передачи сообщения проверки объекта модели между представлениями и действиями. Я не рассматривал использование Tempdata с точки зрения безопасности, но в следующей теме обсуждается то же самое: HttpContext.Items с ASP.NET MVC Смотрите последние несколько комментариев и связанных обсуждений.

...