2015-09-30 5 views
0
déconnecter

Dans mon application web, je suis en train de réaliser la fonctionnalité, qu'un administrateur est capable de déconnecter d'autres utilisateurs connectés.Comment bien d'autres utilisateurs

Ce que je l'ai fait jusqu'à présent:

  • J'ai créé un POJO pour stocker des informations utilisateur importantes, y compris un référenceVoitures aux utilisateurs de la session HTTP.
  • Ce POJO implémente HttpSessionBindingListener
  • Pendant le processus de connexion, j'ai placé une instance de ce POJO dans le SessionMap. Via la méthode valueBound je mets dans une carte statique, qui stocke toutes ces informations d'utilisateur connecté (sur l'événement non lié Je le retire à nouveau
  • Dans une section d'administration séparée, je suis maintenant en mesure d'accéder à la HttpSession d'un utilisateur spécifique et invalident il
  • l'utilisateur connecté-out utilisateur est informé par websocket qu'il a été connecté à

invalidation le HttpSession, fonctionne très bien et la méthode unbound mentionnée est appelée. Cependant, le problème est que si un de cette façon dÉCONNECTÉ utilisateur est toujours capable de faire des requêtes AJAX. est créé et attribué une nouvelle instance de hte ViewScoped Bean à le client et la requête vont à l'encontre de cette nouvelle instance. Ce que j'attendrais (ou ce que je voudrais réaliser) est que sth comme une exception de ViewExpiredException est jetée à la place et redirigeant l'utilisateur à la page de connexion à la place.
Ou est-ce que je manque une partie importante dans mon concept?

Serait-il suffisant pour mettre en place la sécurité appropriées-contraintes web.xml ou serait-il cacher juste le problème conceptuel?

(S'il est important, le haricot est pas un Bean JSF, mais un haricot CDI ViewScoped.)

application est en cours d'exécution sur Glassfish 4.1 ,, Mojarra 2.2.12


SessionBindingListener:

@RequiredArgsConstructor 
@EqualsAndHashCode(of = {"user"}) 
public class UserSessionInfo implements HttpSessionBindingListener { 

    @Getter private static final Map<UserSessionInfo, UserSessionInfo> sessions 
     = new HashMap<>(10); 

    @Getter private final String user; 
    @Getter private HttpSession session; 

    @Override 
    public void valueBound(HttpSessionBindingEvent event) { 
     UserSessionInfo usi = sessions.remove(this); 
     if (usi != null) { 
      HttpSession hs = usi.session; 
      if (hs != null) { 
       hs.invalidate(); 
      } 
     } 
     this.session = event.getSession(); 
     sessions.put(this, this); 
    } 

    @Override 
    public void valueUnbound(HttpSessionBindingEvent event) { 
     sessions.remove(this); 
    } 

} 

Connexion méthode

public String login() { 
     FacesContext context = FacesContext.getCurrentInstance();   
     HttpServletRequest request = 
      (HttpServletRequest) context.getExternalContext().getRequest(); 
     try { 
      request.login(username, password); 
      context 
       .getExternalContext() 
       .getSessionMap().put(username, new UserSessionInfo(/* ...*/))); 
      // .. 
     } 
     // .... 
     return "/index?faces-redirect=true"; 
    } 

Admin-Méthode pour vous déconnecter un autre utilisateur:

public void logoff(UserSessionInfo usr) { 
    EventBus eventBus = EventBusFactory.getDefault().eventBus();   
    eventBus.publish(CHANNEL, new DialogMessage(/*...*/));   
    usr.getSession().invalidate();   
} 

Répondre

0

Si la session de votre utilisateur est vraiment invalidée, toutes les demandes échoue, ajax ou non.

Dans une de mon application, j'ai:

  • restrictions de sécurité, grâce à des rôles dans le suivi de la session web.xml
  • avec un HttpSessionListener et un filtre (le filtre est la façon dont je perçois de nouvelles sessions créées par tomcat lors de la connexion, afin d'éviter la fixation de session)
  • la possibilité de "tuer" une autre session, en utilisant session.invalider

Si une session est recréée "dans votre dos", cela doit être dû au fait que vous avez accès à une zone non restreinte. Exiger auth pour tous vos tout, avec une règle telle que:

<security-constraint> 
    <display-name>Authenticated users</display-name> 
    <web-resource-collection> 
     <web-resource-name>Authenticated users</web-resource-name> 
     <url-pattern>/*</url-pattern> 
     <http-method>GET</http-method> 
     <http-method>POST</http-method> 
    </web-resource-collection> 
    <auth-constraint> 
     <role-name>*</role-name> 
    </auth-constraint> 
    <user-data-constraint> 
     <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
    </user-data-constraint> 
</security-constraint> 

dans web.xml, et il devrait être ok.