Есть ли способ удержать страницу от рендеринга, когда человек вышел из системы, но нажал кнопку "назад"?

Ответ 1

Короткий ответ заключается в том, что это невозможно сделать безопасно.

Есть, однако, множество трюков, которые могут быть реализованы, чтобы затруднить пользователям удары и получить важные данные.

Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(Now.AddSeconds(-1));
Response.Cache.SetNoStore();
Response.AppendHeader("Pragma", "no-cache");

Это отключит кеширование на стороне клиента, однако это не поддерживается всеми браузерами.

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

Ответ 2

Кэш и история независимы и не должны влиять друг на друга.

Единственным исключением созданным для банков, является то, что комбинация HTTPS и Cache-Control: must-revalidate принудительно обновляется при навигации по истории.

В обычном HTTP нет возможности сделать это, кроме как с помощью ошибок браузера.

Вы можете взломать его, используя Javascript, который проверяет document.cookie и перенаправляет, когда установлен куки файл "killer", но я предполагаю, что это может серьезно ошибиться, если браузер не устанавливает/очищает файлы cookie точно так, как ожидалось.

Ответ 3

От aspdev.org:

Добавьте следующую строку поверх обработчика событий Page_Load, и ваша страница ASP.NET не будет кэшироваться в браузерах пользователей:

Response.Cache.SetCacheability(HttpCacheability.NoCache)

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

Ответ 4

Элементы DannySmurf, < meta чрезвычайно ненадежны, когда дело доходит до управления кешированием, а Pragma, в частности, тем более. Ссылка.

Ответ 5

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

Ответ 6

У вас может быть функция javascript, которая выполняет быструю проверку сервера (ajax), и если пользователь не войдет в систему, удаляет текущую страницу и заменяет ее сообщением. Очевидно, это будет уязвимым для пользователя, у которого javascript отключен, но это довольно редко. С другой стороны, это агроничность как браузера, так и серверной технологии (asp/php и т.д.).

Ответ 7

Вы ищете директиву no-cache:

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">

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

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

Ответ 8

Вывести операцию выхода из системы POST. Затем браузер предложит "Вы уверены, что хотите повторно разместить форму?" а не показывать страницу.

Ответ 9

Я не знаю, как это сделать в ASP.NET, но в PHP я бы сделал что-то вроде:

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: no-cache");
header("Pragma: no-cache");

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

Ответ 10

Правильный ответ предполагает использование заголовка HTTP Cache-Control для ответа. Если вы хотите, чтобы они никогда кэшировали вывод, вы можете сделать Cache-Control: no-cache. Это часто используется в координации с не-магазином.

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

См. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

Ответ 11

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

Используя это, вы также можете шифровать любую информацию.

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

Ответ 12

Для полноты:

Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1));

Ответ 13

Хорошо, что в крупной бразильской банковской корпорации (Banco do Brasil), которая известна тем, что имеет одно из самых безопасных и эффективных программ для домашнего банковского дела в мире, они просто ставят history.go(1) на каждой странице. Итак, если вы нажмете кнопку "Назад", вы вернетесь. Простой.

Ответ 14

Пожалуйста, просмотрите заголовки ответов HTTP. Большинство ASP-кода, которые публикуют люди, похоже, настраивают их. Будьте уверены.

бурундук из O'Reilly - это библия HTTP, а HTTP-книга Криса Шифлетта также хороша.

Ответ 15

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

Ответ 16

У меня был только банковский пример.

На странице моего банка есть это:

<meta http-equiv="expires" content="0" />

Это должно быть об этом, я полагаю.