Существует ли способ помешать странице представлять, после того как человек вышел из системы, но нажал “заднюю” кнопку?
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
16 ответов
Короткий ответ - то, что это не может быть сделано надежно.
существует, однако, много приемов, которые могут быть реализованы, чтобы мешать пользователям защищаться и отображать уязвимые данные.
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(Now.AddSeconds(-1));
Response.Cache.SetNoStore();
Response.AppendHeader("Pragma", "no-cache");
Это отключит кэширование на стороне клиента, однако это не поддерживается всеми браузерами .
, Если у Вас есть опция использования Ajax тогда, уязвимые данные могут быть получены с помощью updatepanel, который обновляется от клиентского кода, и поэтому это не будет отображено при защите, если клиент не будет все еще зарегистрирован.
Это - что-то вроде деформации, но если у Вас были апплет Java или приложение флэш-памяти, которое было встроено, и аутентификация была сделана, через который Вы могли сделать его так, чтобы они должны были аутентифицировать в, erm, 'в реальном времени' с сервером каждый раз, они хотели просмотреть информацию.
Используя это Вы могли также зашифровать любую информацию.
всегда существует возможность, что кто-то может просто сохранить страницу с уязвимой информацией о, имение никакого кэша не собирается обходить эту ситуацию (но тогда снимок экрана может всегда делаться флэш-памяти или JAVA-приложения).
Я не знаю, как сделать это в ASP.NET, но в PHP, как который я сделал бы что-то:
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Cache-Control: no-cache");
header("Pragma: no-cache");
, Который вынуждает браузер перепроверить, что объект, таким образом, Ваша проверка аутентификации должна быть инициирована, запретив пользовательского доступа.
Для полноты:
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.Now.AddMinutes(-1));
Вы ищете директиву без кэшей:
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
, Если у Вас есть основное движение дизайна страницы, это может быть чем-то вроде фокуса, но я полагаю, что можно поместить эту директиву на единственной странице, не влияя на остальную часть сайта (предполагающий, что это - то, что Вы хотите).
, Если у Вас есть этот направляющий набор, браузер покорно возвратится к серверу, ища совершенно новую копию страницы, которая заставит Ваш сервер видеть, что пользователь не аутентифицируется, и ударьте его к странице входа в систему.
dannyp и другие, без кэшей, не мешают кэшам хранить чувствительные ресурсы. Это просто означает, что кэш не может служить ресурсу, который это сохранило, не подтверждая его сначала. Если Вы хотите препятствовать тому, чтобы чувствительные ресурсы кэшировались, необходимо использовать директиву без хранилищ.
DannySmurf, < meta> элементы чрезвычайно ненадежны когда дело доходит до управления кэшированием и Прагмой в особенности еще больше. Ссылка .
От aspdev.org :
Добавляют следующую строку сверху обработчика событий Page_Load, и Ваша страница ASP.NET не будет кэшироваться в пользовательских браузерах:
Response.Cache.SetCacheability(HttpCacheability.NoCache)
Настройки это свойство гарантирует, что, если пользователь поражает кнопку "Назад", содержание закончится, и если он нажмет "обновление", то он будет перенаправлен к странице входа в систему.
Кэш и история независимы , и не нужно влиять друг на друга.
единственное исключение сделанный для банков - то, что комбинация HTTPS и Cache-Control: must-revalidate силы обновляется при навигации в истории.
В плоскости HTTP там не является никаким способом сделать это кроме путем использования ошибок браузера.
Вы могли бездельничать он с помощью JavaScript, который проверяет document.cookie и перенаправляет, когда "уничтожающий" cookie установлен, но я предполагаю, что это могло пойти серьезно неправильно, когда браузер не устанавливает/очищает cookie точно как ожидалось.
Перенесите операцию выхода из системы быть POST. Тогда браузер запросит "Действительно ли Вас, уверены, что Вы хотите повторно отправить форму?" вместо того, чтобы показать страницу.
У вас может быть функция javascript, которая выполняет быструю проверку сервера (ajax) и, если пользователь не вошел в систему, стирает текущая страница и заменяет ее сообщением. Это, очевидно, будет уязвимо для пользователя, у которого отключен JavaScript, но это довольно редко. С другой стороны, это не зависит от браузерной и серверной технологии (asp / php и т. Д.).
У Вас может быть веб-страница с чувствительным быть возвращенными как POST HTTP, тогда в большинстве случаев браузеры дадут Вам сообщение, спрашивающее, хотите ли Вы, хотят повторно отправить данные. (К сожалению, я не могу найти канонический источник для этого поведения.)
Изучите заголовки ответа HTTP. Большая часть ASP кодирует это, люди отправляют, надеется установить тех. Убедитесь.
книгой бурундука от O'Reilly является библия HTTP, и , книга HTTP Chris Shiflett хороша также.
Ну, в крупнейшей бразильской корпорации банка (Banco do Brasil), которая известна при наличии одного из worldВґs самого безопасного и эффективного домашнего банковского программного обеспечения, они просто помещают history.go (1) в каждую страницу. Так, при ударе кнопки "Назад" Вы будете возвращены. Простой.
Корректный ответ включает использование установки заголовка Управления Кэша HTTP на ответе. Если Вы хотите удостовериться, чтобы они никогда не кэшировали вывод, можно сделать Управление Кэша: без кэшей. Это часто используется при взаимодействии с без хранилищ также.
Другие опции, если Вы хотите ограниченное кэширование, включают установку, истекает время, и должен - подтверждать, но они могли потенциально все заставить кэшируемую страницу быть отображенной снова.
См. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
Я только что имел в виду пример банковского дела.
На странице моего банка есть это:
<meta http-equiv="expires" content="0" />
Это должно быть об этом, я полагаю.