C encore moi mais cette fois-ci c pas une question code mais plutôt en général:
J'utilise l'envoi de session_id() dans l'url par

 
Lorsque l'utilisateur se déconnecte, j'utilise session_destroy()
 
Mais lorsque je copie l'url avant de déconnecter, que je me déconnecte puis que je colle l'ancienne url, par ex.

, ben la page s'affiche correctement.
Cela signifie que si j'envois ma copie d'url à un ami, il peut se connecter sur mon compte sans passer par l'identification.
 
Ca veux donc dire que mon idée de passer l'id en url pour permettre de contourner la protection de confidentialité de IE, n'est pas super sécuritaire.
 
Bref, j'ai vu plein de post et de sujets là-dessus mais au final personne ne donne la meilleure méthode pour contourner le blocage de connection par IE (lorsque la confidentialité est moyenne ou haute) sans passer par les cookies tout en étant pas mal niveau securité.
 
Merci de vos conseils car je crois qu'ils en aideront plus d'un...  

Sans utiliser de cookies, point de salut. Et encore, c'est pas la meilleure solution. Faut du SSL par dessus pour être à peu près valable

Tu es face un probleme que beaucoup de personne se posent. Il faut absolument utiliser un cookie et pour que ton amie puisse avoir la meme page il faut que tu lui donne ton cookie. Il faut rajouter d'autre élément qui font que tu réduis le risques au maximum en sachant bien que tu n'aura jamais la protection ultime. tu peux jouer sur l'ip (s'il sont tous les deux derriere le meme routeur c'est mort). Navigater (s'ils utilisent les navigateurs c'est mort). L'os (il y a de grande chance qu'ils utilisent windows, c'est mort). Configuration ecran (il y a des chances mais si c'est le même c'est mort). Tous réuni reduit le risque.

JAMAIS L4ADRESSE IP MALHEUREUX §§§§

Je sais et j'ai expliqué pourquoi  !

Y'a aussi les proxy AOL... Et quand un de tes premiers clients est justement sur AOL, t'as interêt à gaffer

Tu peux très bien garder l'IP du client et si pas pareil qu'à l'authentification on se reloggue  
C'est pas bloquant, juste éventuellement chiant pour celui qui a une ligne pourrie et pas d'IP fixe
Prendre en compte les X_FORWARDED_FOR pour les proxies respectueux.
 
Et surtout détruire physiquement les sessions qui n'ont plus lieu d'être, ou contourner le problème en logant la session et son timestamp de dernière activité et passé un certains temps, poubelle
 
Sinon un truc con, plutot que le session destroy qui destroye rarement comme il faudrait, tu vides la session de l'info identifiante
 
Pas de solution miracle comme dit, juste qu'en siblant une information presque sûre et en la gérant directement t'es presque sûr

Et surtout chiant pour ceux sous AOL dont l'IP change à chaque page Et inutile pour ceux qui sont derrière NAT. Du coup, super facile de se faire des crasses entre collègues

Bon donc en gros :
1/ Tout système informatique est fragile
2/ Toujours coder en passant à la solution compatible avec la majorité des systèmes tout en gardant en tête le fait que c'est vulnérable
 
Merki pour vos réponses en tout cas

idée , peut ete bete:
 
tu stockes dans une BDD qui est connecté deconnecté avec les session_id
 
en plus du session_destroy , tu efface la ligne dans la BDD  
 
ca devrait eviter la réutilisation de session_id ,non?
 
de plus une table contenant les personnes logguées/deloggués rend des services interessant au niveau du tracage de la charge du serveur

L'IP AOL change à chaque requête http
Je savais pas parce que j'y ai jamais eu à faire, c'est hallucinant comme principe, c'est quand qu'ils respectent les standarts eux    

en meme temps qu'IE    
 

L'an prochain alors? Attention, ca pourait vite arriver alors.