J'utilise l'authentification Tomcat de base pour mon application Web:
J'ai ajouté les lignes suivantes sur web.xml dans mon application Web: p> mon lien de déconnexion: public void logout() throws IOException
{
FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
FacesContext.getCurrentInstance().getExternalContext().redirect("add_international_job.faces");
}
3 Réponses :
Vous utilisez HTTP Forcer une "déconnexion" sur BASIC code> Authentification au lieu de HTTP Formulaire CODE> Authentification avec J_Security_Check code>. L'authentification Basic code> est effectuée par Authorisation code> Demande d'en-tête du côté du navigateur, qui est indépendante de la session. basique code > Authentification, le serveur doit essentiellement retourner une réponse 401. P> FacesContext facesContext = FacesContext.getCurrentInstance();
ExternalContext externalContext = facesContext.getExternalContext();
externalContext.invalidateSession();
externalContext.setResponseStatus(401);
externalContext.getResponseOutputWriter().write("<html><head><meta http-equiv='refresh' content='0;add_international_job.faces'></head></html>");
facesContext.responseComplete();
Merci multiplier 10000000000000000 sur la puissance 1000000000000000000
@Evilpenguin: C'est le navigateur indépendant. Votre problème concret est probablement causé par le côté du client. Peut-être que le cache de navigateur?
Qu'en est-il d'utiliser le bouton "BACK" après le 401?
public void logout() throws IOException {
HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
try {
request.logout();
} catch (ServletException ex) {
throw new IOException(ex);
}
}
Cela ne fonctionne malheureusement pas pour l'authentification de base. Il ne efface que l'utilisateur du côté serveur, pas du côté du client. Le navigateur se souvient jusqu'à ce que l'instance du navigateur soit sortie, indépendante du cookie de session. La demande suivante recréerait simplement l'utilisateur. Le serveur a vraiment pour retourner une réponse 401. La méthode () fonctionne toutefois bien pour l'authentification basée sur le formulaire par j_security_check ou authentification programmatique par Connexion () .
C'est quelque chose de complètement différent. Vous utilisez l'authentification de base pour valider un utilisateur. Ceci invite le navigateur pour un nom d'utilisateur et un mot de passe sur la première demande. À partir de ce moment-là, le navigateur envoie automatiquement le nom d'utilisateur et le mot de passe sur toutes les demandes suivantes sur le même serveur, votre authentification basée sur le Web les réjouit simplement de rentrer. La session est invalidée et tout ce que vous avez mis aura lieu, mais vous ne pouvez pas Obtenez le serveur pour repompre l'utilisateur d'un nom et d'un mot de passe. Il continuera à envoyer le même nom d'utilisateur et le même mot de passe sur le même hôte jusqu'à ce que vous fermiez le navigateur. Ceci est un inconvénient à l'authentification de base.
J'utilise généralement ma propre authentification car elle permet plus de liberté, mais vous êtes responsable de vous assurer que toutes vos ressources sont protégées. Un moyen facile de le faire est d'utiliser des jambes de force et de remplacer les servlets d'action effectuez une méthode pour l'authentification. Vous créez votre propre page de connexion au lieu de disposer du navigateur de mettre en place une boîte de dialogue de connexion. Vous vérifiez que quelqu'un est connecté en enregistrant une variable à leur session et en vérifiant que VAR lorsqu'il s'agit de demandes. Si le Var est défini, ils vont bien. Sinon, vous les redirige dans la page de connexion. Invalidation de la session enregistre une personne.
Suggérant à utiliser des jambes de force et de servlets pour créer un cadre d'authentification cultivé à domicile dans le contexte d'une question connexe de la JSF-2 est un peu étrange ...