Флэш-сообщение, основанное на Cookie или Session - PullRequest
11 голосов
/ 16 мая 2011

Отличительной особенностью, которую я нашел в CakePHP, была возможность установить сообщение flash, скажем, на каком-то скрипте save, и затем отобразить это сообщение на следующей странице.Что-то вроде Post updated или Error - no file found.

То, как Cake делает это, с этим session объектом.Я стараюсь избегать таких сессий, как чума, из-за их странных требований к масштабируемости.Могу ли я не просто сохранить флэш-сообщение в файле cookie (на стороне клиента), а затем удалить этот файл cookie, как только он отобразится на следующей странице?Какие плюсы и минусы у этого подхода - или, проще говоря, почему Cake использует session (я предполагаю, что это относится к коллекции _SESSION).

Cheers!

ps В моей реализации я также заставляю его исчезать с помощью команды setTimeout в javascript.Я считаю, что это хороший способ завершить весь процесс.

Ответы [ 4 ]

4 голосов
/ 23 мая 2011

Проблема с cookie заключается в том, что пользователь может отключить эту функцию.Если это так, ваше сообщение не будет отображаться.CakePHP старается быть достаточно общим и использует хранилище сеансов.

У вас есть 3 варианта:

  1. Сеанс : наиболее часто используемый подход.Он будет работать на любом клиентском компьютере, но, как вы говорите, он может вызвать проблемы с некоторыми конфигурациями сервера.
  2. Cookies : в общем, это хороший вариант, но пользователь может заблокировать этот механизм,Рекомендуется, только если требования вашего приложения включают в себя необходимость использования файлов cookie.
  3. База данных : универсальное решение.Проблема в том, что требуется доступ к базе данных (медленно).Идентификатор должен передаваться вместе с URL (метод GET), чтобы приложение знало, какой регистр базы данных соответствует этому доступу.

В моих приложениях я использую комбинацию 2-го и 3-го подходов: я проверяюкуки и если они есть, я их использую.Если нет, я использую доступ к базе данных, НО я всегда кеширую доступ к БД, чтобы не запрашивать более одного раза для каждого сообщения.

4 голосов
/ 17 мая 2011

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

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

Простая реализация может быть чем-то процедурным, например:

function setFlash($id ,$message){
   setcookie("flash_{$id}", $message, time() + 60 * 10);
}


function getFlashes(){
   $flashes = array();
   foreach($_COOKIE as $id => $value){
        if(strpos($id, "flash_") === 0){
             $flashes[$id] = $value;
             //clear flash and set expiration to 10 minutes in past
             setcookie($id, "", time() * 60 * -10);

         }
  }
  return $flashes;
   //Input cleansing not included for brevity/clarity
}

В качестве альтернативы, если флэш-память исходит только изна стороне клиента вы можете использовать что-то вроде https://github.com/marcuswestin/store.js, чтобы попытаться использовать локальное хранилище для управления флэш-сообщениями.

0 голосов
/ 22 октября 2018

Сессии, к сожалению, не всегда надежны, когда за ними следует заголовок («Местоположение ...»);

Я думал о том, чтобы поместить его в запрос GET или тег Hash, как было предложено, и вы можете стереть его на следующей странице, используя javascript из URL, используя window.history.pushState.

Редактировать: если не используется session_write_closed (); используется.

0 голосов
/ 15 марта 2013

Другой идеей является передача сообщения через хеш в URL:

if (isset($_POST['submit'])) {
    ...
    header("Location: ".$_SERVER["REQUEST_URI"]."#".urlencode($msg));
    ...
}

Преимущества:

  • Работает без файлов cookie / сессий / баз данных / memcaches и т. Д.: -)
  • Не зависит от клиентских часов, как куки
  • Никакой другой запрос клиента не может "украсть" сообщение

Недостаток:

...