Забороніть користувачеві бачити раніше відвідану захищену сторінку після виходу

У мене є вимога, щоб кінцевий користувач не міг повертатися на сторінку з обмеженими можливостями після виходу / виходу. Але в даний час кінцевий користувач може це зробити за допомогою кнопки повернення браузера, відвідування історії браузера або навіть шляхом повторного введення URL-адреси в адресному рядку браузера.

В основному, я хочу, щоб кінцевий користувач не міг жодним чином отримувати доступ до сторінки з обмеженим доступом після виходу. Як я можу досягти цього найкращого? Чи можна відключити кнопку назад за допомогою JavaScript?

Ви можете та не повинні вимикати кнопку повернення чи історію браузера. Це погано для роботи користувачів. Є хакі JavaScript, але вони не є надійними, а також не працюватимуть, коли у клієнта JS відключений.

Ваша конкретна проблема полягає в тому, що запитувана сторінка завантажується з кешу браузера, а не прямо з сервера. Це по суті нешкідливо, але дійсно заплутано для ендузера, оскільки він / він помилково вважає, що це дійсно з сервера.

Вам просто потрібно доручити браузеру не кешувати всі обмежені сторінки JSP (і, таким чином, не тільки сторінку виходу / саму дію!). Таким чином браузер змушений запитувати сторінку на сервері замість кешу, і тому всі перевірки входу на сервер будуть виконані. Це можна зробити за допомогою фільтра, який встановлює необхідні заголовки відповідей у doFilter()методі:

@WebFilter
public class NoCacheFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;

        response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
        response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
        response.setDateHeader("Expires", 0); // Proxies.

        chain.doFilter(req, res);
    }

    // ...
}

Наприклад, картографуйте це Filterза url-patternінтересами *.jsp.

@WebFilter("*.jsp")

Або якщо ви хочете розмістити це обмеження лише на захищених сторінках, вам слід вказати шаблон URL-адреси, який охоплює всі ці захищені сторінки. Наприклад, коли вони всі знаходяться в папці /app, вам потрібно вказати шаблон URL-адреси /app/*.

@WebFilter("/app/*")

Навіть більше, ви можете виконувати цю роботу так само, Filterяк і там, де ви перевіряєте наявність зареєстрованого користувача.

Не забудьте очистити кеш браузера перед тестуванням! ;)

Дивитися також:

• Фільтр аутентифікації та сервлет для входу
• Як контролювати кешування веб-сторінок у всіх браузерах?

* .jsp в Url Pattern не працюватиме, якщо переслати сторінку. Спробуйте включити і ваш сервлет .., що зробить вашу програму захищеною від цієї проблеми із кнопкою "назад".

Найпростіший спосіб зробити це, не відключаючи кнопку назад у веб-переглядачі, - додавши цей код у page_loadподію для сторінки, на яку ви не хочете, щоб користувач повертався після виходу з системи:

if (!IsPostBack)
    {
        if (Session["userId"] == null)
        {
            Response.Redirect("Login.aspx");
        }
        else
        {
        Response.ClearHeaders();
        Response.ClearContent();
        Response.Clear();
        Session.Abandon();
        Session.Remove("\\w+");
        Response.AddHeader("Cache-Control", "no-cache, no-store, max-age = 0, must-revalidate");
        Response.AddHeader("Pragma", "no-cache");
        Response.AddHeader("Expires", "0");
        }
    }

Ви можете спробувати сказати браузеру не кешувати домашню сторінку (використовуючи відповідні заголовки - Expires, Cache-Control, Pragma). Але це не гарантовано працює. Що ви можете зробити, це здійснити дзвінок ajax на сервер на завантаженні сторінки, щоб перевірити, чи користувач увійшов у систему, а якщо ні - перенаправити.

Правильний спосіб зробити це - додати

Vary: Cookie

заголовок на захищених сторінках. Коли користувач вийде, очистіть його cookie сеансу. Потім, коли вони повернуться назад після виходу, кеш браузера буде пропущений. Це також має перевагу не повністю перемогти кешування.