Comment faire la différence entre déconnexion et session expirée ?

Question

Cas 1 : Déconnexion : Une fois que l'on s'est déconnecté, si l'on essaie d'accéder au site précédent, il doit automatiquement rediriger vers login.jsp.

Cas 2 : Session expirée : Si la session expire alors que l'utilisateur est toujours connecté, il doit essayer de rediriger automatiquement vers sessionExpired.jsp lors de l'accès à la page précédente.

Comment faire la différence ? Je suis en train d'invalider la session lors de la déconnexion.

Answer 1

Lors de la connexion, définissez un cookie avec une longue durée d'expiration (> 24 heures). Supprimez ce cookie au moment de la déconnexion en définissant le maxage à 0.

Vous pouvez vérifier si un utilisateur ne s'est pas connecté (c'est-à-dire si son ID de session est invalide). Si le cookie n'existe pas, redirigez-le vers login.jsp.

Si le cookie existe, cela signifie que sa session a expiré, alors redirigez-le vers session-expired.jsp.

Answer 2

Vous pouvez tester les sessions expirées en vérifiant si HttpServletRequest#getRequestedSessionId() ne renvoie pas null (ce qui signifie que le client a envoyé un cookie de session et suppose donc que la session est toujours valide) et HttpServletRequest#isRequestedSessionIdValid() renvoie à false (ce qui signifie que la session a expiré du côté du serveur).

Dans une noix :

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws ServletException, IOException {
    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;
    HttpSession session = request.getSession(false);

    if (request.getRequestedSessionId() != null && !request.isRequestedSessionIdValid()) {
        response.sendRedirect(request.getContextPath() + "/sessionexpired.jsp");
    } else if (session == null || session.getAttribute("user") == null) {
        response.sendRedirect(request.getContextPath() + "/login.jsp");
    } else {
        chain.doFilter(request, response);
    }
}

Pas besoin de s'embêter avec des biscuits supplémentaires. Cette carte Filter sur un url-pattern couvrant les pages protégées (et excluant donc les pages sessionexpirée et login !).

N'oubliez pas de désactiver la mise en cache des pages par le navigateur sur les pages protégées, sinon le navigateur web les chargera depuis le cache lorsque vous reviendrez en arrière dans l'historique du navigateur, au lieu d'envoyer une nouvelle requête au serveur. Vous pouvez y parvenir en faisant ce qui suit dans le même filtre, avant Chain#doFilter() appeler.

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.

Answer 3

Si c'était moi, j'effacerais la session lors de la déconnexion et je créerais un bool dans celle-ci appelé HasLoggedOut, puis je le mettrais à true. Si ce bool existe dans la session, vous savez que l'utilisateur s'est déconnecté. Si ce n'est pas le cas, soit la session a expiré, soit l'utilisateur ne s'est jamais connecté.

Comme vous ne pouvez toujours pas faire la différence entre un délai d'attente et une absence de connexion, je décide normalement que s'ils demandent une page authentifiée, je les enverrai simplement à la page de délai d'attente de session qui sert également de page de connexion et qui dit quelque chose comme

"Oups, nous ne savons pas qui vous êtes, soit votre session a expiré, soit vous ne vous êtes pas encore connecté, veuillez vous connecter ci-dessous".

Cela permet de répondre aux deux scénarios