2016-02-02 2 views
0

Я разрабатываю свой первый проект, и я прочитал некоторое чтение о состоянии поддержки на разных страницах. С тех нескольких часов, которые я потратил на эту тему, похоже, что сериализация и несессиализация с использованием $ _SESSION кажутся довольно простым и эффективным.

Тем не менее, кажется, чтобы получить неодобрение из-за двух основных (и часто оспариваемым) причинам:

  • Performance
  • Security

У меня есть очень типичный (3 страницы) приложения процесс в рамках моего проекта 1> Выбрать категорию 2> Данные ввода 3> Подтверждение => Добавить в базу данных. И имеет смысл хранить информацию о моем объекте в $ _SESSION.

На переднем плане времени для сериализации объекта было около 4 микросекунд, а для несериализации было 5 микросекунд.

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

На фронте безопасности я понимаю, что информация о сеансе хранится на сервере, так что это не безопасно?

Я понимаю, что это было предложено раньше, но ближе всего я нашел было предложено 7 лет назад

PHP: Storing 'objects' inside the $_SESSION

И искал более до даты мнений.

ответ

0

TL; DR: ИМХО хранящие объекты в сессии не то, что большая часть большой сделки, если в рамках требований системы

длинная история: Это действительно зависит от требований/спецификаций системы , т.е. веб-сервер является общим, и каждый может читать память сеанса ... тогда я не буду хранить его в сеансе: P ... я бы не хранил сеанс вообще

С точки зрения требований: требуется, чтобы пользователь может забрать, где он остановился во время процесса? Если это так, я бы использовал «постоянный» магазин (т. Е. Хранилище данных). Если это процесс, который не может быть возобновлен (действителен только в течение текущего сеанса), я бы не стал хранить его в хранилище данных.

В качестве обеспечения безопасности: если ваш веб-сервер скомпрометирован, возможно, они также могут получить доступ к серверу базы данных (например: получить информацию входа в БД из ваших сценариев и т. Д.). Это означает, что ваши данные все равно скомпрометированы. В любом случае, они могли бы получить данные, если захотят.

Мое предложение в вашем случае от вашего чтения: просто используйте сеанс для него, поскольку он намного проще реализован (меньше кода)

Смежные вопросы