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

голоса
24

У меня есть сайт, который требует входа в систему и показывает секретную информацию.

Человек идет к странице, будет предложено войти в систему, а затем получает, чтобы увидеть информацию.

Человек выходит из сайта, и перенаправляется обратно на страницу входа в систему.

Человек тогда может ударить «назад» и вернуться обратно на страницу, где содержится чувствительная информация. Так как браузер просто думает о нем, как оказанной HTML, он показывает им это не проблема.

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

Ради аргумента, выше сайта / сценарий в ASP.NET с помощью форм аутентификации (так что, когда пользователь переходит на первую страницу, которая является страница, что они хотят, они перенаправляются на страницу входа в систему - в случае, что делает разница).

Задан 15/09/2008 в 16:41
источник пользователем
На других языках...                            


16 ответов

голоса
3

От aspdev.org :

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

Response.Cache.SetCacheability(HttpCacheability.NoCache)

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

Ответил 15/09/2008 в 16:44
источник пользователем

голоса
0

Вы ищете директивы в не-кэш:

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

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

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

Ответил 15/09/2008 в 16:44
источник пользователем

голоса
0

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

Ответил 15/09/2008 в 16:44
источник пользователем

голоса
0

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

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

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

Ответил 15/09/2008 в 16:45
источник пользователем

голоса
0

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

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

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

Ответил 15/09/2008 в 16:45
источник пользователем

голоса
0

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

С помощью этого вы можете также шифровать любую информацию.

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

Ответил 15/09/2008 в 16:55
источник пользователем

голоса
0

Для полноты картины:

Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1));
Ответил 15/09/2008 в 16:59
источник пользователем

голоса
1

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

Ответил 15/09/2008 в 17:10
источник пользователем

голоса
1

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

Ответил 15/09/2008 в 17:14
источник пользователем

голоса
0

Ну, в крупном банке бразильские корпорации (Banco ду Бразил), который, как известно, имея один из самых безопасных world's и эффективный домашний банковского программного обеспечения, они просто положить history.go (1) в каждом page.So, если вы попали кнопку назад, вы будете возвращены. Просто.

Ответил 15/09/2008 в 19:13
источник пользователем

голоса
13

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

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

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

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

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

Ответил 17/09/2008 в 23:48
источник пользователем

голоса
0

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

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

Ответил 20/09/2008 в 07:00
источник пользователем

голоса
9

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

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

В простом HTTP нет никакого способа сделать это за исключением использования багов браузера.

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

Ответил 19/10/2008 в 23:57
источник пользователем

голоса
0

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

Ответил 06/01/2009 в 17:17
источник пользователем

голоса
0

Я просто имел банковский пример в виде.

Страница моего банка имеет это в нем:

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

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

Ответил 20/04/2009 в 10:48
источник пользователем

голоса
1

Вы могли бы иметь Javascript функция делает быструю проверку сервера (AJAX), и если пользователь не вошел в систему, стирает текущую страницу и заменяет его с сообщением. Это, очевидно, будет уязвимо для пользователя чьего Javascript выключен, но это довольно редко. На верху, это как браузер и серверные технологии (ASP / PHP и т.д.) агностиком.

Ответил 20/04/2009 в 16:53
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more