Terminé, j'ai vérifié la requête respective (implémentation de HttpServletRequest) de Tomcat et Jetty, et ils ont tous défini l'identifiant de session via un setRequestedSessionId(String). Si j'utilise la réflexion pour obtenir et appeler cette méthode, définissez-la avant getSession. sessionId, après test sur Jetty, cela fonctionne, puis essayez Tomcat. Ces deux conteneurs sont ceux que j'utilise couramment et j'examinerai d'autres conteneurs lorsque je les rencontrerai.

Le code est simple :

    try {
        request.getClass ()
             .getMethod("setRequestedSessionId", String.class)
             .invoke   (request , id);
    } catch ( NoSuchMethodException ex) {
        // Log
    } catch (IllegalAccessException |
           IllegalArgumentException |
          InvocationTargetException ex) {
        // Log
    }

Haha !

Il convient de noter qu'il doit être exécuté avant que la requête actuelle n'appelle getSession pour la première fois. Faites particulièrement attention à savoir s'il existe un filtre dans la couche supérieure qui utilise Session

2016/05/21 Résultats expérimentaux mis à jour

Le SessionID peut être remplacé par la méthode ci-dessus, mais la session ne peut pas être supprimée, car la session sera vérifiée une fois supprimée, et le code source de Jetty sera suivi pour découvrir que l'objet Session est défini lorsque la Requête est initialisée, comme indiqué ci-dessous :

Pour le moment, Servlet et Filter n'ont pas été effectués, il n'y a donc aucun moyen de démarrer, il semble donc que la réinitialisation ne soit pas si simple.

Ce qui précède a été testé uniquement sur Jetty, et le résultat a échoué. Il n'y a aucune expérience avec Tomcat. Si vous regardez le code source, il existe une méthode changeSessionId(String) qui devrait être possible en fonction de la logique.

Résultats à nouveau mis à jour le 21/05/2016

Après un lancer constant, le sessionId a été réinitialisé avec succès à l'aide du code suivant :

    try {
        Object obj;
        obj = req.getClass ()
           .getMethod("getSessionManager")
           .invoke   (req);
        obj = obj.getClass ()
           .getMethod("getHttpSession" , String.class)
           .invoke   (obj, sid);
        req.getClass ()
           .getMethod("setSession", HttpSession.class)
           .invoke   (req, (HttpSession) obj);
    } catch ( NoSuchMethodException ex ) {
        // Log
    } catch (IllegalAccessException  |
           IllegalArgumentException  |
          InvocationTargetException ex ) {
        // Log
    }

Rien ne doit être modifié dans le programme exécuté après cela. Vous pouvez utiliser request.getSession() pour lire et écrire la session normalement. Cette méthode est écrite pour Jetty.

Mise à jour des mesures réelles Tomcat du 22/05/2015

Je m'ennuyais après le petit-déjeuner, alors j'ai suivi le code Tomcat, en utilisant les versions Tomcat 7 et 8, et j'ai découvert que l'objet Request remis à l'utilisateur Servlet est une classe proxy appelée RequestFacade, qui ne fonctionne que sur les méthodes de HttpServletRequest. Sans l'implémentation, son objet Request est masqué, donc setRequestedSessionId et les autres méthodes de org.apache.catalina.connector.Request ne peuvent pas être appelées.

Il semble que ce Hack ne puisse être implémenté que pour Jetty.

Bien que les résultats ne soient pas optimistes et que Jetty puisse cacher ces méthodes dans les versions futures, ce processus expérimental nous a permis de mieux comprendre ces deux conteneurs d'applications. Qu'il s'agisse de cookies, de paramètres de chemin d'URL ou de paramètres GET/POST, ils transportent simplement le jeton de session à différents emplacements des données de la requête. Il peut être plus pratique d'encapsuler simplement la connexion côté client

Utilisez le jeton et placez le jeton dans l'en-tête de la requête. Le front-end est tenu d'apporter ce token lors des demandes