salut !
je suis en train de développer un site en jsp ! et je rencontre ma première difficulté ; en effet, un utilisateur doit pouvoir se logger et bénéficier de droits spécifiques (invité, membre ou admin). Mais voilà, je ne sais pas quoi faire après qu'il ait valider son login et son mot de passe. Je pense utiliser un cookie combiné à une session. Je souhaite utiliser un cookie de façon à se que l'utilisateur que s'est identifié n'ai pas à retapper son login et mot de passe à chaque fois qu'il revient sur le site. Mais que faut il mettre dans ce cookie ? le login et le mot de passe ? J'en doute, alors quoi ?
 
Une fois que c'est fait, j'ajoute la session dans une base de données (table session avec, comme informations : id de la session, adresse ip de l'utilisateur, id de l'utilisateur).
Est-ce une bonne solution ?
 
Merci d'avance pour votre aide !  

Dans le cookie, tu peux mettre le mot de passe et le nom d'utilisateurs, mais codés. ET laisse le choix à l'utilisateur de stocker ou non ce données (il choisi s'il préfère retaper son mot de passe à chaque fois), avec un case à cocher par exemple.
Ensuite, mettre une session en base de données, j'vois pas trop l'intéret (si ce n'est pas des stats). N'oublies pas que dans les JSP t les servlet, tu peux récupérer la session d'un utilisateur ayant émis chaque requète HTTP à traiter :
HttpServletRequest -> getSession() pour les servlets.
session est utilisable tel quel dans toutes les JSP.

non, c'est pas la bonne solution ...
 
quel est l'intérêt de mettre en base l'id de session ?? je comprend pas bien là ...
 
La session est gérée pour toi par le moteur de servlet. Dans l'objet "session", il y aura tous les attributs que tu y aura stocké.
 
ex : quand le gars se loggue, tu vérifie son identification, si c'est OK, tu stocke en session l'id de l'utilisateur et éventuellement d'autres infos .. ensuite dans tes pages, pour savoir à qui tu as à faire, tu regarde l'id en session ...
 
sinon, pour le cookie, le plus simple c'est de stocker en cookie le login/mot de passe. La page d'accueil de ton site vérifie si les cookies sont présents dans la requête, Si ce n'est pas le cas ou que l'identification est mauvaise, tu redirige vers la page de login, si c'est bon, tu stocke les infos en session et tu laisses passer ...
 
bordel !!!

Je vous remercie !    
Je sens que je t'ai énervé Benou -> ...(c)  

pas toi, c'est le gringo qui m'a grillé ! de 4 minutes en plus

pq tout le monde tiens absolument à stocker le mdp en cookie!? comprend pas...

et si tu donnais la bonne façon de faire à la place de faire ton gros malin ?

je fais pas le "gros malin" je comprend pas pq on veut foutre un password dans un cookie, je vois pas l'interet de le rebalancer au serveur a chaque fois... pour moi le seul truc qu'il doit y'avoir dans le cookie c'est le session id.
et si l'utilisateur est trop feignant et pas parano et qu'il veut pas retaper son mdp, bah son browser a un "password manager" ..

ben ouais faut pas le rebalancer à chaque fois ...
 
moi ce que je fais c'est que je me débrouille pour que ma page de vérification de l'identitée soit dans un repértoire spécial (ex : /ident/) et je fixe le path de cookie à ce repertoire, comme ca, le cookie n'est balancé que lorsqu'on va sur cette page. Sur les pages du site, je vérifie (avec un filtre) à chaque fois qu'on est identifié. Si c'est pas le cas, je redirige (HTTP 302)l'utilisateur vers la page d'ident (en stockant la page qu'il avait demandé en session) => il balancera son cookie. Si l'identification fonctionne, je le redirige vers la page qu'il avait demandé à l'origine, sinon c'est qu'il a pas de cookie ou que l'ident a échoué et je lui sers la page d'identification;
 
Comme ca, ca passe le password qu'une seule fois, au moment de l'identification, de la même façon que si c'était le browser qui l'envoyait par un formulaire

ben oui donc quel interet de le stocker dans un cookie

il a pas à le ressaisir à chaque fois ...

à chaque fois que quoi

ben si tu stocke pas dans le cookie, il devra repasser par la page d'identification à chaque fois qu'il ira sur le site ...
 
tu fais exprès de pas comprendre ou quoi

non, je comprend mtnt, mais je suis tjs pas convaincu... je vois l'utilité mais bon en meme temps cliquer sur "login" c'est pas mortel, et ça me parait unpeu plus safe

ben ouais mais bon, déjà tout le monde ne se sert pas du password manager du browser et dans certains cas, c'est une demande du client que le login puisse être automatique donc pas trop le choix ...
 
et puis d'un point de vue sécurité, sur le réseau c'est pareil, c'est juste du^côté du disque client où il y a son password dans un cookie. Là y a un risque, que tu peux minimiser en criptant le bazard, mais ca reste un point sensible...
C'est également vrai pour le password manager du browser, mais bon là c'est mieux planqué  

ben, tout le monde ne se sert pas du pw manager, certes, mais c'est leur problème, et j'aurais la meme réponse à un client.  
enfin bon, oui, je sais qu'il y en a des chiants et obtus.
mais à priori, en tous cas, j'irai pas faire ça

le client veut, le dev s'execute
 
nan, et puis sérieusement, je trouve ca très user-friendly (j'adore cette expression !!! ) l'identification transparente !

ben ça je dis pas, mais...
crypté ou pas, ton mdp est dans ton cookie. une ame malveillante passe, le choppe, et vlan. (qu'il soit crypté ne change rien à l'affaire, c pas bien compliqué de simuler l'envoi d'un cookie au lieu d'un formulaire, je suppose...)
cliquer sur login c'est un peu moins user friendly, mais tant que t'es renvoyé à la bonne page, ça va, et c'est plus rassurant je trouve.

bha, dans tous les cas, si le site doit être secure, c'est clair que stocker le mot de passe dans un cookie, ca va pas
si c'est pas la cas, y a aucun problème à de l'identification transparente ..

ouais... ok

\o/
 

ben disons que la limite entre un site qui doit etre secure et qui doit pas est quand meme mal définie

rhoooo t'abuse, on était arrivé à ce mettre d'accord et t'en rajoute une chouche

 
D'ou l'intéret de propose à l'utilisateur de stocker ou non le mot de passe. Une petite case à cocher "stocker les données d'identification" à la page de login, avec un p'tit avertissement sur la sécurité si le gars la coche. Et pouf pouf, le tour est joué et tout le monde est d'accord.
Et puis ton histoire de password manager ça va pas ça. T'es pas censé te fier aux fonctionnalités de tel ou tel navigateur quand tu développes un site...

el_gringo >> ok pour la casacocher. pour le pwdman, je m'y "fie" pas, je dis que c'est l'utilisateur qui a cette possibilité s'il a la flemme de retaper son password. autrement dit la fonctionalité du pwdman n'apparaitrait pas dans mes specs, mais ça serait une réponse à la question que me poserait le "client"

C'est à cause de réactions de ce genre que je souhaite utiliser des cookies
 
Sinon, savez-vous s'il est possible de lister toutes les sessions en cours ? dans le style getIds()    
C'est pour faire, une liste de tous les connectés.

 
Si c'est possible, je n'sais pas comment. J'avais besoin d'un truc dans le style, du coup je m'suis fait un petit singleton qui maintient une référence vers toutes les sessions actives (utilise javax.servlet.http.HttpSessionBindingListener)

pas besoin de ça
attend une minute

ha ben ptet pas finalement; y'avait HttpSessionContext mais c'est deprecated et pas remplacé

Ouais, il y avait une façon de le faire avant mais ca a été déprécié ...
si tu veux le faire, il faut le faire à la main => enregistrer chaque nouvelle session dans une Collection que tu collera au Context par exemple ...

ok, je vous remercie. Je vais regarder du côté de HttpSessionBindingListener.
Par contre, par rapport à ce que tu as écris Benou, on ne peut plus rien coller au Context puisque toutes les méthodes qui s'en approchent sont dépréciées

SessionListener devrait suffir
et si tu peux ajouter des attributs au context hein: javax/servlet/ServletContext.html#setAttribute(java.lang.String, java.lang.Object)

 
Heuuu... ça existe ça ? Parce que dans ma doc des Servlet 2.3, y a pas!

de quoi ? ServletContext setAttribute ou SessionListener?

HttpSessionListener quoi..

ben si ... setAttribute() ca marche toujours ... c'es juste que tu ne peux plus récupérer les instances de servlets et des sessions ...

dis benou tu lis un peu les posts des autres?

la remarque m'étais faite directement à moi donc je répond
 
et puis de toute façon, comme (encore une fois) tu avais pas quoté la phrase à laquelle tu répondais, t'as rien à dire
 
je vais voir avec antp si y a moyen de te bannir de réponse rapide

euh ben je répondais au post juste au dessus
en commençant ma phrase par "tu peux ajouter des attributs au context" en plus...
moi je trouve le forum plus lisible sans quotes inutiles

<darkmode>
ta gueule
</darkmode>