Как предотвратить переход пользователя обратно, на защищенную страницу, после того как он разлогинился?

Question

[KhanTengri]

Сразу скажу, что я не думаю, что решение этой проблемы зависит от того, на чем реализована серверная часть(Ruby, Python, PHP, JSP, ASP.NET, etc.), поэтому я опускаю тут этот момент.

В общем допустим, что пользователь в данный момент залогинен и находится в своем профайле(profile.htm). Далее он решает разлогиниться и нажимает на соответствующую ссылку(logout.htm). logout.htm удаляет куки из браузера, объекты связанные с юзером на сервере и редиректит его на страницу login.htm. Но вот вопрос: как предотвратить переход пользователя обратно, на profile.htm, если он(или кто-то другой) нажмет кнопку «Go Back» в браузере?
Браузер кеширует страницу профайла и предыдущие тоже, что позволяет нажатием «Go Back» просмотреть их все по цепочке… Все ссылки на этих страницах будут, конечно же, уже не активны, но кешированные данные о пользователе(допустим: email, name etc.) можно увидеть.

Как предотвратить такое поведение системы?
Я имею ввиду стандартные способы, не хочется изобретать велосипед.


UPD: Короче говоря, какого-то законченного решения проблемы я так и не нашел.

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

Другое решение на javascript, с использованием history.forward(), работает не везде. Например, в последней версии Firefox(Firefox4) — это не работает. Также, при выключенном javascript…

С точки зрения реализации более правильный способ тот, что предлагает VolCh: добавление http-заголовков, вроде Cache-Control:no-cache, no-store, must-revalidate; Pragma:no-cache; Expired:0. Ведь лучше просто не закидывать браузеру в кеш то, что после logout захочется оттуда удалить. Это логичный и простой способ достичь указанной мной цели. Хабр, кстати, тоже после логина возвращает заголовки с этими аттрибутами. Однако, этот подход так же работает не везде. Я протестировал на Firefox, Chrome, Opera и Safari. В первых двух случаях браузер ожидаемо не позволял переходить назад после logout, во вторых двух — позволял…

В общем, на данный момент я останавливаюсь на способе с http-заголовками.

PS: Кстати, очень полезной оказалась вот эта ссылка:
stackoverflow.com/questions/4194207/restrict-user-from-accessing-the-previous-page-after-signout

Comments

[KhanTengri]

Я знаю про 'no-cache' в заголовках к страницам, которые браузер не должен кешировать. Но в таком случае увеличивается нагрузка на сервер. Есть так же вариант с history.forward(), но у меня в Firefox4 это не работает. Все страницы, в том числе и содержащие этот код прекрасно окрываются.

Answer 1

[Hast]

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

Comments

[KhanTengri]

Ну это потенциальная дыра в безопастности. Если ты сидишь на работе, на каком-то web-портале, потом нажимаешь logout и отходишь от компа ненадолго. Любой посторонний человек сможет подойти и нажав кнопку «Go Back» браузера фактически зайти в ваш профайл! Пусть не в полной мере(чтоб все ссылки работали), но какую-то инфу он сможет узнать. Это не есть good

[KhanTengri]

Добавлю еще, что при таком поведении системы вы фактически не выполнили функцию logout в полной мере. Вы просто скинули часть данных о пользователе…

Answer 2

[vinxru]

Сделать пустую страницу, которая делает AJAX запрос и выводит результат на экран (в innerHTML).
Серверный код (почти наверняка) даже не придется менять.
При нажатии на «назад», страница сделает повторный AJAX запрос, но данных уже не получит.

Answer 3

[Марк]

Отправляйте HTTP-заголовок Vary: Cookie. Это стандартный способ отдавать разные страницы при потере сессии, странно что никто еще не написал.

Реализация этого зависит от браузера, конечно.

Answer 4

[Олег Матрозов]

Хм… нестандартно и костыльно. На profile.htm разместить JS проверяющий наличие кукисов, кукисов нет — делаем редирект или еще что куда надо.

Comments

[Hast]

Теоретически, страница всё-равно останется в кеше, а в таком случае пропадает всякий смысл от такого решения

[Олег Матрозов]

Ну, совсем нестандартно и совсем костыльно… делать в profile.htm подгрузку данных аяксом, в кеше то может и останется, а вот увидеть будет уже сложнее.

Но… вы уверены, что оно того стоит? И… вы уверены, что страницы распространяемые по https вообще разрешено кешировать?

Answer 5

[himik]

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

Comments

[Hast]

Вот, кстати, да. У меня тоже самое. Либо абсолютно все сайты уже оснащены такой фичей, а я как лох о ней не знаю, либо всё происходит автоматически.

[KhanTengri]

@himik Я как раз и и пытаюсь выяснить как так можно сделать :-) Есть решение с использованием history.forward(). Этот javascript работает отлично в Chrome не позволяя возвращаться на страницы, где он размещен. Скорее всего именно так там, где вы были и реализовано, но! НО history.forward() не работает на Firefox… по крайней мере в FF4 у меня это не пашет…

[Алексей]

Помнится, в какой-то версии Оперы это не работало, то есть проверил почту, разлогинился, нажал Бэк — и видишь снова письма. А Хром вот так делать не дает. Нигде. Видимо, при нажатии на Back идет не просто возврат к кешу страницы, но и её автообновление уже без кук входа.

[himik]

@KhanTengri
window.history.forward(); очень себе даже работает в фоксе.
но вообще мне кажется неправильным запрещать пользователю пользоваться кнопкой назад

[KhanTengri]

>>window.history.forward(); очень себе даже работает в фоксе.
Я незнаю, что сказать… Я пробую и не работает… Не знаю, что за дел а такие… =)
А по поводу того, что неправильно запрещать пользователю возвращаться назад — ведь даже на Хабре это у вас не получилось, ведь так? А Хабр — это просто блог-платформа(ну, по сути ;)), тут даже к деньгам отношения никакого нет и тем не менее — нельзя!
Я уже выше написал, что подобное поведение системы — это дыра в безопасности. И по сути это не logout, а лишь частичное удаление данных о пользователе.

[himik]

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

[KhanTengri]

[offtop] С днем рождения! :-) [/offtop]

Answer 6

[Владимир Чернышев]

Запретить кэширование браузеру различными http заголовками типа Cache-Control, Expires, Pragma: no-cache.

Правда есть браузеры, которым плевать на стандарты и запреты. И это даже не IE, а Opera (если ничего не изменилось за последнее время)

Comments

[KhanTengri]

Ну да… Я уточнил к вопросу, что знаю про установку разных http-заголовков, вроде 'no-cache' и проч. Но просто это реально сильно будет грузить сервак. Так как пользователю на портале незалогиненным по большей части просто нечего делать, а все залогиненные не будут кешироваться браузером…

[Владимир Чернышев]

Выдавать на приватных страницах Last-Modified, браузер будет запрашивать If-Modified-Since, скрипт проверяет залогинен ли пользователь и если нет, то временный редирект на страницу логина, Если залогинен то или тупо отрисовать страницу, или проверить может она действительно не изменилась (или ничего важного не изменилось, на какие-нибудь мелочи можно и забить) и выдать 304 Not Modified. Во втором случае нагрузка будет меньше, чем рисовать страницу полностью. Хотя без «хаков» типа принудительной инвалидации без запросов к БД не обойтись, по-моему.

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

Answer 7

[iStyx]

Подсказка: страницы, полученные по https, не кэшируются браузерами

Comments

[Владимир Чернышев]

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

[KhanTengri]

>>Человеку нужно и кэширование, пока пользователь залогинен, и резкая очистка кэша браузера, когда разлогинивается.
Exactly!

[fluxion]

> страницы, полученные по https, не кэшируются браузерами

Кэшируются, если это разрешить в настройках. Как минимум, в Опере это возможно.

[Дмитрий Сидоров]

тогда это проблемы пользователя…

Answer 8

[Сергей Береснев]

Можно сделать изощрённо: все страницы отдавать в зашифрованном виде(и пусть оно кэшируется), плюс на странице скрипт. Этот скрипт делает ajax запрос, который получает ключ(который выдаётся на сессию) и пытается расшифровать страницу и отобразить что получилось. Если не получилось, то обновляем текущую страницу. Так будет каждый раз выполняться запрос, но достаточно простой, а основная часть страницы будет закэширована браузером.