К вопросу кеширования веб-страниц и кнопки "назад"

К вопросу кеширования веб-страниц и кнопки "назад"

Собственно вопрос исходит из желания пользователей сайтов, требующих регистрации и авторизации быть спокойными после логаута, когда, в ряде случаев при нажатии на кнопку "назад" в браузере некто может увидеть те страницы с защищаемой информацией, которые были видны до "разлогинивания"

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

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

Первое и самое важное

  • Использовать HTTPS. Без этого фактора говорить дальше о безопасности контента нет смысла
  • Выдавая важный контент, посылать заголовок Cache-Control: must-revalidate

Чего делать не надо

  • Посылать всевозможные заголовки <meta> в <head> страницы
  • Использовать заголовки post-check/pre-check - это специфические для IE заголовки, применимые к кешируемым ресурсам
  • Дублировать несколько раз одни и те же хедеры, последовательно изменяя их смысл.

Что можно сделать еще

  • no-store, если посылаем защищаемую информацию
  • no-cache, или max-age=0, это делает ресурс всегда устаревшим, и браузер запрашивает актуальную версию страницы (хотя must-revalidate делает тоже самое)
  • Expires с датой в прошлом, что работает для клиентов, привязанных к протоколу HTTP/1.0 (но что его реально сейчас использует?)

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

Комментарии (0)

mem: 1162 total: 11 module: 5 xsl: 3