>> Насчёт мяукания не знаю — ни разу не видел оповещения с web-страницы.
Я обновил текст своего вопроса, вы не могли бы проверить, будет ли работать оповещение?
>>window.history.forward(); очень себе даже работает в фоксе.
Я незнаю, что сказать… Я пробую и не работает… Не знаю, что за дел а такие… =)
А по поводу того, что неправильно запрещать пользователю возвращаться назад — ведь даже на Хабре это у вас не получилось, ведь так? А Хабр — это просто блог-платформа(ну, по сути ;)), тут даже к деньгам отношения никакого нет и тем не менее — нельзя!
Я уже выше написал, что подобное поведение системы — это дыра в безопасности. И по сути это не logout, а лишь частичное удаление данных о пользователе.
Ну да… Я уточнил к вопросу, что знаю про установку разных http-заголовков, вроде 'no-cache' и проч. Но просто это реально сильно будет грузить сервак. Так как пользователю на портале незалогиненным по большей части просто нечего делать, а все залогиненные не будут кешироваться браузером…
@himik Я как раз и и пытаюсь выяснить как так можно сделать :-) Есть решение с использованием history.forward(). Этот javascript работает отлично в Chrome не позволяя возвращаться на страницы, где он размещен. Скорее всего именно так там, где вы были и реализовано, но! НО history.forward() не работает на Firefox… по крайней мере в FF4 у меня это не пашет…
Ну это потенциальная дыра в безопастности. Если ты сидишь на работе, на каком-то web-портале, потом нажимаешь logout и отходишь от компа ненадолго. Любой посторонний человек сможет подойти и нажав кнопку «Go Back» браузера фактически зайти в ваш профайл! Пусть не в полной мере(чтоб все ссылки работали), но какую-то инфу он сможет узнать. Это не есть good
Я знаю про 'no-cache' в заголовках к страницам, которые браузер не должен кешировать. Но в таком случае увеличивается нагрузка на сервер. Есть так же вариант с history.forward(), но у меня в Firefox4 это не работает. Все страницы, в том числе и содержащие этот код прекрасно окрываются.
>>А то что вы описали «сделано кое-что» может быть очень малым
Да я и не говорю, что я прям весь воздух тут перекрыл =) Я не хотел вдаваться в специфику, поэтому так загадочно выразился.
Я просто не хотел уходить в специфику своего сайта, поэтому так загадочно написал «кое-что» =)) Мое приложение реализовано на jsp/servlets и для предотвращения SQL-injection я использую PreparedStatements при выполнении всех запросов к базе. Впрочем, я не уверен, что этого достаточно. На xss у меня написан servlet-фильтр, который заменяет символы ",',<,>,& в запросах на аналогичные html-мнемоники.
Вы не могли бы уточнить, как так можно sql-injection укрыть в header'е или EXIF? Впервые сталкиваюсь с таким и даже вот так сразу представить себе не могу как они могут выполниться, будучи там…
В таком случае каждый раз при попытке открыть папку со стилями пользователем появляется окошко с просьбой авторизоваться. Если оставить шаблон '/css/*', то даже jsp-страничка использующая стили из этой папки потребует от пользователя ввести логин/пароль…
А со значением DEFAULT в <auth-method> у меня так ничего и не заработало…
В целом, конечно, это не совсем то, что надо… Но тем не менее тоже способ, спасибо +1
Да нет, если бы это можно было включить и выключить, то не вопрос! Но в том то и дело, что избавиться от этого пока никак не получалось. Приходится изголяться…
По реализации это обычное веб-приложение, работающее с базой данных. Ничем особенным не отличающееся, от того же интернет-магазина, к примеру. Очередной агрегатор чего-то там…
Да, я знаю об этом варианте, я наткнулся на него в этой статье. Но, все же, возможно ли сделать как-то по-иному? Мне почему-то кажется, что это нестандартное решение.
Я обновил текст своего вопроса, вы не могли бы проверить, будет ли работать оповещение?