[Listener]Recuperer l'adresse Ip à partir de la session.

Bonjour !

Dans mon application je cherche à recupérer l'adresse ip d'un utilisateur démarrant une nouvelle session.
Je sais le faire sans problème en utilisant la requete avec la commande :

Code:

---

request.getRemoteAddr()

---

Cependant, l'endroit où je souhaite récuperer l'adresse ip est dans la méthode "public void sessionCreated(HttpSessionEvent ev)" d'un HttpSessionListener, et comme vous pourrez le remarquer, il n'y a pas de parametre de type HttpRequest, donc impossible d'utiliser la methode precedement citée. Il faut donc que je recupère le HttpRequest à partir du "HttpSessionEvent" (à partir duquel j'arrive déjà à récupérer le "HttpSession") ou que je trouve une autre methode me permettant d'obtenir l'ip de l'utilisateur.

Si quelqu'un à une solution, je suis preneur !
Merci d'avance !

J ai chercher a le faire aussi mais je ne pense pas que cela soit possible!!!
dsl

Fait un ServletFilter et met l'ip dans un ThreadLocal...
Attention à l'utilisation des IP tout de même, tu n'as AUCUNE garantie que l'ip récupérée soit celle de l'utilisateur qui émet la requete !!!

Pourquoi l'ip que je recupererai pourrai ne pas etre celle de l'utilisateur ayant emis la requete ? Je doit avouer que ca devient trop technique pour moi et je ne suis pas expert en reseau. Mais je pensais que l'IP c'etait l'identifiant de connexion, donc meme si ca change a chaque reconnexion avec l'ip dynamique, durant la session l'utilisateur ne conserve-t-il pas la meme adresse ip ?

Salut,

Citation:

---

Envoyé par Jaxofun

Mais je pensais que l'IP c'etait l'identifiant de connexion, donc meme si ca change a chaque reconnexion avec l'ip dynamique, durant la session l'utilisateur ne conserve-t-il pas la meme adresse ip ?

---

Je n'en suis pas sûr à 100% mais cette IP peut changer, en particulier si l'utilisateur est derrière un routeur NAT...
Si le routeur NAT possède plusieurs adresses publiques, il est possibles que deux requêtes successif n'ai pas la même adresse IP étant donné que le protocol HTTP est en mode déconnecté...

Mais pourquoi avez-vous besoin de vérifier les IPs ?
Pour identifiez l'utilisateur le sessionID est généralement suffisant...

a++

Je verifie les IP pour éviter qu'un même utilisateur ne lance plusieurs sessions ! Evidemment s'il change d'ip entre temps je ne pourrais le reperer, cependant ça diminue le nombre de session "abandonnées" qui n'attendent que le timeout pour disparaitre !

De nombreuses entreprises utilisent des routeurs NAT, ainsi que la plupart des solutions de partage de connection internet fonctionne avec du NAT... Donc en te basant sur les IPs, il y a un risque (important?) qu'un utilisateur se retrouve avec la session d'un autre...

C'est pour cela que les cookies de sessions sont utilisées à la place des IPs pour 'reconnaitre' l'utilisateur...

Est-ce que tu encodes bien tes URL avec la méthode encodeURL() de ton HttpResponse pour gérer les cas où les cookies sont désactivées chez le client ??? Sinon tu risque bien de te retrouver avec une nouvelle session par page...


a++

Je n'attribut pas une session en cours à un nouvel utilisateur ayant la meme IP, je supprime seulement cette ancienne session. Ce qui fait qu'aucun utilisateur ne se retrouve avec la session d'un autre.
Je releve juste l'IP de l'utilisateur lors de l'ouverture de sa session.

Par contre je n'utilise pas de cookies et n'encode pas l'URL de mon httpResponse (je ne connais pas encodeURL(), vais me renseigner dessus)

Citation:

---

Envoyé par Jaxofun

Je n'attribut pas une session en cours à un nouvel utilisateur ayant la meme IP, je supprime seulement cette ancienne session. Ce qui fait qu'aucun utilisateur ne se retrouve avec la session d'un autre.
Je releve juste l'IP de l'utilisateur lors de l'ouverture de sa session.

---

OK, dans ce cas il n'y a pas de risque de se retrouver avec la session d'un autre... mais par contre tu risques quand même d'avoir des problèmes.

Un exemple : deux clients se connectent depuis leurs entreprise qui utilise un routeur NAT (ils ont donc tous les deux la même IP).
[list]Le client 1 se connecte et crée une session (que tu associes avec l'IP).
Le client 2 se connecte et crée également une session, mais comme son IP est déjà présente, tu supprimes la session du client 1.
Le client 1 change de page, comme sa session a été détruite, il en crée une nouvelle, et comme son IP existe déjà, la session du client 2 est supprimée...
etc...[/quote]
Grosso modo dans ce cas là tu peux te retrouver à recréer une nouvelle session à chaque page... du coup ta session ne sert plus à rien car tout est perdu à chaque fois...

Citation:

---

Envoyé par Jaxofun

Par contre je n'utilise pas de cookies et n'encode pas l'URL de mon httpResponse (je ne connais pas encodeURL(), vais me renseigner dessus)

---

En réalité tu utilises déjà des cookies... En effet les serveurs d'applications web J2EE utilisent les cookies de sessions pour 'reconnaître' les clients (justement parce qu'ils ne peuvent pas se baser sur leurs IPs) en conservant le sessionID qui permet de retrouver la session.
Pour rappel, un cookie de session est un cookie qui est supprimé lors de la fermeture du navigateur.

Quand à la méthode encodeURL(), elle devrait normalement être appellé sur tous les liens de ton application...
En effet, la plupart du temps cette méthode ne fait rien... mais si les cookies du client sont désactivés, alors cette méthode rajoute le sessionID à la fin de l'URL, par exemple mapage.jsp deviendra mapage.jsp:SID=123456789 (je ne suis pas sûr à 100% du format exact). Ceci afin de pouvoir récupérer la session de l'utilisateur...


Je suppose que si tu veux faire cela, c'est que tu te retrouve avec beaucoup de sessions 'inutiles'... il vaut mieux cibler les causes exactes plutôt que de se baser sur les IPs...

a++

En fait, j'effectue des messages de log specifique à chaque client. C'est à dire que pour chacun des utilisateur je crée un fichier de log ayant pour nom l'IP du client (ex : 185.12.13.45.log ).
Je voulait donc eviter qu'un fichier effectue des messages de log "mélangés" de 2 sessions qui s'effectueraient en même temps.

Tes eclaircissements mon beaucoup aider à mieux comprendre les limites d'une identifiaction par IP et vais donc changer le fonctionnement de mon appli.

Merci beaucoup AdiGuba, ainsi qu'à SEMPERE Benjamin et Alwin !