
К вопросу кеширования веб-страниц и кнопки "назад"
Собственно вопрос исходит из желания пользователей сайтов, требующих регистрации и авторизации быть спокойными после логаута, когда, в ряде случаев при нажатии на кнопку "назад" в браузере некто может увидеть те страницы с защищаемой информацией, которые были видны до "разлогинивания"
Прежде всего тут нужно сделать ремарку, что исходя из современного веба, это в принципе невозможно. Таков протокол 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)