La gestion de session est Dropwizard 0.8.x

Quelqu'un peut-il me donner un aperçu de la façon dont j'implémente la gestion de session dans Dropwizard 0.8.x ou au-dessus. J'utilisais Dropwizard 0.7.0 jusqu'à maintenant et j'y travaillais parfaitement. Mais je suis vraiment confus par les documents de changement fournis lorsque j'ai migré vers 0.8.x.La gestion de session est Dropwizard 0.8.x

Dans Dropwizard 0.7.0 (que j'utilisais précédemment), il a été fait comme le

/*MainApplication.class session handler */ 
environment.jersey().register(HttpSessionProvider.class); 
environment.servlets().setSessionHandler(new SessionHandler()); 


/*Resource.class session check*/ 
HttpSession session = httpServletRequest.getSession(true);

Mais il ne semble fonctionner plus, dire précisément HttpSessionProvider.class est pas là et remplacé par un autre implémentations.

Il serait vraiment utile que quelqu'un montre à quoi cela est changé. Merci.

Source

2015-12-11 Yash Krishnan

Hey, avez-vous essayé d'injecter la session dans votre méthode de ressources? Par exemple. dans mon application je fais: @Context HttpServletRequest dans la signature de la méthode. Cela fonctionne à coup sûr, et vous pouvez ensuite obtenir le HttpSession à partir de votre objet de demande. Vous serez probablement en mesure d'injecter la session directement dans votre méthode de ressources. – pandaadb

@pandaadb: J'ai utilisé '@Context' ici, mais la session n'est pas maintenue entre les requêtes. Quelque chose est étrange. De même, devons-nous enregistrer les fournisseurs de sessions comme dans les anciennes versions? –

Je n'avais pas à m'enregistrer et je n'ai jamais regardé en détail ce qui se passe dans la session. Mais maintenir la session, cela n'arriverait-il pas du côté des clients? Par exemple. le serveur obtient juste ce qu'il obtient. Le code dans HttpSessionProvider ne fait rien d'autre que d'appeler obtenir sur la demande elle-même. Dans une version ultérieure de dropwizard, le fournisseur est remplacé, je pense avec SessionFactoryProvider – pandaadb

La raison pour laquelle cela ne fonctionne pas pour vous est que vous devez définir le cookie dans la réponse. J'ai remarqué ceci tout en cherchant à activer l'état de session pour une application dropwizard où le cookie sous-jacent est créé sur l'objet Jetty Response mais il ne fait jamais son chemin sur l'objet Jersey Response et est donc abandonné.

Ce que j'ai fait pour contourner ce problème consiste à implémenter un filtre qui extrait les informations «Set-Cookie» de Jetty et le place sur l'objet de réponse sortant.

   String cookie = HttpConnection. 
        getCurrentConnection() 
        .getHttpChannel() 
        .getResponse() 
        .getHttpFields().get(HttpHeader.SET_COOKIE.asString()); 

      if (LOG.isDebugEnabled()) { 
       LOG.debug("Adding session cookie to response for subsequent requests {}", cookie); 
      } 

      httpServletResponse.addHeader(HttpHeader.SET_COOKIE.asString(), cookie);

Source

2016-12-06 14:30:43 user1316072

@Yashwanth Krishnan

Je sais que c'est vieux, mais je remarque que la session n'a pas été maintenue d'une URL à un autre, il suffit d'ajouter ce code lorsque vous initialiser le demande, la gestion de session est la plupart du temps un conteneur chose et non spécifique à DropWizard.

SessionHandler sessionHandler = new SessionHandler(); 
sessionHandler.getSessionManager().setMaxInactiveInterval(SOME_NUMBER); 

    /** 
    * By default the session manager tracks sessions by URL and Cookies, we 
    * want to track by cookies only since 
    * we are doing a validation on all the app not URL by URL. 
    */ 
    sessionHandler.getSessionManager().setSessionTrackingModes(EnumSet.of(SessionTrackingMode.COOKIE)); 

    environment.servlets().setSessionHandler(sessionHandler);

Source

2017-08-04 21:04:50 Bambara

La gestion de session est Dropwizard 0.8.x

Répondre

Questions connexes