web-dev-qa-db-fra.com

Comment puis-je empêcher Spring-security d'ajouter; jsessionid = XXX pour les redirections de connexion?

Lorsqu'un client non authentifié demande une URL nécessitant un niveau d'accès non anonyme tel que défini dans security-config.xml, Spring Security envoie une redirection HTTP à notre page de connexion (par exemple, /login). C'est très bien.

Le problème est que, en l'absence d'une session existante (identifiée par un cookie fourni dans la demande du client), Spring-Security émet une redirection qui spécifie également la nouvelle session du client dans l'URL, par exemple. /login;jsessionid=8o7pglapojus.

De nombreux conteneurs supportent cela (apparemment, cela fonctionne très bien dans tomcat?), Mais il semble que Jetty (ce que nous utilisons actuellement) ne le fait pas - l'URL redirigé parvient à notre routeur d'URL complètement intact (y compris la jsessionid " paramètre "), et la session nommée n’est pas associée à la demande /login par jetty/spring-security (c’est-à-dire qu’un tout nouvel ID de session est fourni dans l’en-tête Set-Cookie de la réponse à la demande /login).

Nous pouvons contourner ce problème en faisant correspondre /login.* à nos routes, mais je suis curieux de savoir s'il est possible d'empêcher l'émission de l'identifiant de session dans la redirection d'authentification pour commencer.

tomcatservletsspring-securityjetty
31
cemerick

Dans Spring Security 3.0.0 M1 ou plus récent, vous pouvez définir disable-url-rewriting="true" dans l'espace de noms <http>. Voyez si cela aide. Voir aussi cette demande de fonctionnalité .

43
BalusC

Maintenant, ça ressemble à ça.

<security:http auto-config="false" use-expressions="true" disable-url-rewriting="true">

Après cela, votre application ne pourra plus exécuter correctement les tâches avec état.

8
Naeem

Depuis que vous utilisez jetty, ajoutez simplement la balise context-param suivante dans votre web.xml,

<!-- Disables appending JSESSSIONID in browser address bar/requests -->
<context-param>
    <param-name>org.Eclipse.jetty.servlet.SessionIdPathParameterName</param-name>
    <param-value>none</param-value>
</context-param>

Référez-vous à: Session Management - Jetty Doc

1
Lucky

Voici comment j'ai résolu ce problème ... 

le scénario était que je disposais de peu de sessions de sécurité et de pages security = "none" et, lors de la redirection du post-envoi - URL de redirection utilisée pour s’ajouter; Jsessionid = in url - bien sûr, entraînant des erreurs ... 

En outre, je ne pouvais pas ajouter disable-url-rewriting = "true" également ne fonctionnait pas. 

Ce qui a fonctionné pour moi si le code ci-dessous est indiqué dans soumission sur soumission de formulaire

HttpSession session = request.getSession();
if (session != null) session.invalidate();

cela garantissait qu’il n’y avait pas de session active - ce qui garantit que Spring lors de la soumission après redirection n’a pas besoin de transporter les informations de session, et donc inutile d’ajouter JSESSION à l’URL. 

C’était bien sûr nécessaire pour mon cas spécifique… et ne peut pas être utilisé comme solution générique pour l’ensemble de l’application. Faites-moi savoir si cela vous aide. 

0
Anand Tuli

J'ai déjà ajouté une réponse à cela pour des cas d'utilisation spécifiques - voici plusieurs façons de le résoudre (résumant mon parcours de découverte et mes expériences) 

  1. @ niveau général - n'assure aucun niveau de réécriture d'URL

<sec:http pattern="/<your url pattern>/**" disable-url-rewriting="true"

  1. assure qu'aucune information de session n'est nécessaire, donc pas besoin d'ajouter JSESSSIONID

<%@ page session="false" %>

  1. @ Contrôleur - avant de diriger vers page/url, invalide la session. Aucune session> Aucune information de session À emporter> Aucune annexe JSESSIONID

HttpSession session = request.getSession(); if (session != null) session.invalidate();

Ces solutions sont spécifiques à la sécurité de printemps. Il y a d'autres solutions qui peuvent être faites au niveau Tomcat 

  1. modification du suivi de session en COOKIE, informations de session déjà avec le cookie du navigateur> Pas besoin de transmettre des informations dans l'URL> Pas d'ajout de JSESSIONID [ne fonctionne pas lorsque les cookies ne sont pas autorisés, j'ai rencontré le problème avec Safari/Opera Browsers + Chrome avec paramètres de cookie tiers strict]

<session-config> <tracking-mode>COOKIE</tracking-mode> </session-config>

  1. disableURLRewriting au niveau du serveur Web

Dans WEB-INF/web.xml disableURLRewriting = "true"

J'espère que cela vous aide. 

0
Anand Tuli

Une autre solution est ici (pour ceux du Spring Security, c'est-à-dire moi-même)

http://randomcoder.com/articles/jsessionid-considered-harmful

Crée un wrapper de filtre de servlet et gère le traitement.

0
AhmetB - Google

@ahmet alp balkan:

seamframework fournit une meilleure solution que les randomcoders http://seamframework.org/Documentation/RemovingJSESSIONIDFromYourURLsAndFixingScache

@BalusC:

Si le développeur a utilisé FilterChainProxy de Spring Security pour implémenter la fonctionnalité securtiy, n'utilisez pas d'espace de nom http.

Ensuite, nous n'avons pas pu trouver un moyen d'ajouter disable-url-rewriting sans essayer d'ajouter un filtre personnalisé à la chaîne de filtrage ou d'insérer un filtre indépendant dans web.xml. 

0
cleverpig