[Résolu] Session unique

Bonjour,

Voilà je suis étudiant en informatique, et je travail sur un projet personnel en PHP/MySQL.

Mon but est de faire un site, où un utilisateur peut se connecter (identifiant/mot de passe), et accéder au contenu.

Et je veux que, si depuis une autre IP, un autre utilisateur se connecte avec le même identifiant, le premier soit alors déconnecté.


La solution simple est de créer une session en PHP, et à l'identification, on écrit dans la base de registre l'IP du client. A chaque page on vérifie si l'IP du client est la même que celle de l'utilisateur.

Si une seconde personne vient se connecter utilisant le même compte, il remplace son IP dans la base, et peut alors naviguer. Le premier quant à lui se verra refuser le contenu à sa prochaine requête.

Je sais faire ça.


Ma question est, est-il possible de faire la même chose sans effectuer de requête SQL à chaque requête HTTP ?

J'ai 3 solutions à mon problème

1) Ecrire dans un fichier les correspondances Utilisateur/IP
2) Ecrire dans un $tableau les correspondances Utilisateur/IP
3) Quand le second utilisateur se connecte, cela supprime la $_SESSION de l'utilisateur précédent

Le cas 1 ne me plait pas, celà revient au même qu'effectuer une requête.

Le cas 2 je ne sais pas faire, je ne sais pas s'il est possible d'avoir un tableau qui serait global à l'instance de PHP même

Le cas 3 je ne sais pas faire, communiquer les $_SESSION entre-elles...



Que me conseillez-vous ?

(Je suis très axé performance)
Modifié par Baud (15 May 2007 - 17:55)

Baud a écrit :
Et je veux que, si depuis une autre IP, un autre utilisateur se connecte avec le même identifiant, le premier soit alors déconnecté.

Euh... Pour quoi faire ?

Soit cet "autre" utilisateur est le même (ce qui semble logique puisqu'il connaît le login/password) qui se reconnecte après une déconnexion ou après avoir couru dans le cybercafé le plus proche (pour la déconne ) -> auquel cas il suffit de laisser "mourir" sa première session qui a certainement un timeout.
Soit c'est un hacker qui a trouvé le login/password -> auquel cas, pourquoi lui donner la priorité par rapport au premier ?

Soit le login/password est connu de plusieurs personnes (genre admin/admin) -> auquel cas : mais pourquoi ne pas en créer un pour chaque user ?

Cela étant dit, j'avais déjà cherché un moyen de faire ce que tu suggères dans le point 2 (pour connaître les connectés à un "espace membres") et je n'avais pas trouvé d'autre moyen que d'écrire/supprimer dans une table les connectés/déconnectés.
Idem pour le point 3 : je ne crois pas que cela soit possible (dans la mesure de mes humbles connaissances ...)

A+
Modifié par Heyoan (14 May 2007 - 23:13)

Le point 3 est tout simplement impossible... Une session est unique et tu ne peut pas accéder a une session autre qu'as celle en cours sur le navigateur...
Logique sinon l'utilisation de session ne serai pas sécurisée...
Moi j'ai fait un compteur de visite et pour réduire les requêtes SQL, je stocke l'ip dans un cookie et je vérifie selon certaines conditions... Si l'ip a changer je la met a jour dans ma BDD.

Le but, c'est d'interdit d'avoir 2 sessions simultanées pour un même compte.

Le dernier identifié aura la seule session valable pour ce compte.

Je ne veux pas qu'on puisse se servir d'un même compte depuis 2 pc différent, voir même, 2 navigateurs différents.

Donc je vais m'en résoudre a effectuer une requête supplémentaire à chaque page...

Merci quand même!

Une question d'utilisabilité : est-ce que tu ne penses pas que ce serait mieux de refuser la connexion au deuxième qui se connecte plutôt qu'au premier ?

Exemple :
Je suis le premier connecté, je navigue un peu, et tout à coup pendant ma navigation, je vois un message du genre "vous avez été déconnecté". Frustrant, non ?

Si je prends le cas inverse, je suis le deuxième qui essaie de se connecter, je valide le formulaire de connexion et je vois un message "Ce comte est en cours d'utilisation". Ca m'apparaît comme beaucoup moins frustrant que d'être coupé en pleine navigation...

Sinon, tu ne peux pas faire autrement que de stocker une information soit dans ta base SQL, soit dans un fichier. Deux sessions ne peuvent communiquer entre-elles et il n'existe pas de variables superglobales qui seraient communes à toutes les instances de php en cours d'exécution. Primo ça pourrait être dangereux pour la sécurité, et deuxio le système utiliserait de toute façon également un fichier pour stocker ces variables, sans que tu ne le saches, ce qui reviendrait donc quasiment au même...

a écrit :
Une question d'utilisabilité : est-ce que tu ne penses pas que ce serait mieux de refuser la connexion au deuxième qui se connecte plutôt qu'au premier ?

+1. Rien à ajouter . Be user-friendly.
Modifié par yodaswii (15 May 2007 - 09:34)

Ok imagine alors que tu te connecte depuis un poste. Ensuite, tu le quitte sans fermer proprement ta session.

Tu vas ailleurs et t'essai de te déconnecter. Malheureusement, tu dois attendre la fin de la session sur l'autre poste...

Ou tout simplement, tu surf sur mon site, t'es déconnecté de l'Internet. Tu n'as pas une IP fixe de ton cher FAI, tu revisite mon site, la connexion t'es refusé, car l'ancien toi est toujours dessus.


Les 2 façons de voir existent, par exemple, sur mon routeur, si j'essai de me connecter alors que je le suis déjà depuis un autre PC, la connexion est refusée (c'est un exemple de ton idée)
Un exemple qui illustre mon idée, c'est le jeu Counter Strike, avec les comptres SteamID. Tu joue au jeu, et si quelqu'un vient a s'identifier avec ton compte, tu es alors déconnecté du jeu. C'est la même chose pour MSN, si tu te connecte a ton compte, alors que tu l'étais déjà depuis un autre poste, tu remplace sa session !


Je pense qu'on a fait le tour de la question!

Désolé, je ne partage pas du tout ton avis.

En effet, la plupart des utilisateurs ne se déconnectent pas d'eux-même.
A toi de régler la durée de vie de tes sessions ; si ils sont déconnectés ils se reconnectent !

a écrit :
C'est la même chose pour MSN, si tu te connecte a ton compte, alors que tu l'étais déjà depuis un autre poste, tu remplace sa session !

Ce n'est pas un exemple ; tu files même le pire exemple qui soit ... un webmail dont les utilisateurs ne cessent de se faire hacker ...

Enfin bref, fais comme tu veux ... mais j'ai la même vision que QuentinC. L'utilisateur ne doit pas être lésé et cette façon de faire n'épargne pas l'utilisateur (qui comprendra mieux d'avoir été déconnecté pour cause de passivité plutôt que par cause d'une autre connexion à son compte).

Ne pas pensez FIFO (First In First Out) but User-friendly ... boudiou !

Imaginons alors ceci:




Cas d'utilisation:

1) Un usager s'identifie au serveur. Il le quitte sans fermer proprement sa session.
2) Il retourne sur le serveur avec une autre IP, sa session va remplacer la session existante.


Cas d'un piratage XSS:

1) Un usager se fait voller son identifiant de session (attaque XSS).
2) L'hacker envoie une requête, le serveur remarque la différence des IP, la requête du hacker est refusée, par sécurité, la victime aussi (on supprime l'entrée de l'IP de la victime dans la table)
3) La victime envoie une requête (en se croyant connecté), et le serveur lui demande de se reconnecter, et peut utiliser a nouveau son compte.
La session est recrée, et donc l'identifiant volé est obselete, le hacker doit tout recommencer.


Le but est de protéger contre les attaques de ce type.

Bonjour,

Les tests basés sur l'IP de l'utilisateur ne sont pas fiables (passage par un proxy par exemple).

Si l'utilisateur passe par un proxy, alors toute personne utilisant le même proxy aura même IP et donc la vérification ne donnera rien.

Baud a écrit :
Si l'utilisateur passe par un proxy, alors toute personne utilisant le même proxy aura même IP et donc la vérification ne donnera rien.

Il me semble bien que dans certains cas, l'IP de l'utilisateur peut changer en cours de navigation (changement de proxy ?).

Si la détection de l'IP est fiable, pourquoi est-ce que les sites grand public ne l'utilisent pas ?

Parce que les grands sites n'ont pas besoin d'avoir une session unique. Au pire s'il veulent avoir une telle sécurité, ils passent en HTTPS...