Discussion :

[benthebest]

Désolé pour le titre explicite

Bonjour,

Donc comme indiqué, j'aimerai savoir par quel moyen le plus fiable je peux permettre qu'un utilisateur à la fois qui s'authentifie à son compte et éviter ainsi 2 ou plusieurs connexions simultanées à un même compte.

Pour l'instant j'ai trouvé la solution de créer une sorte de flag is_connected dans la DB = 1 si il s'est authentifié et = 0 lorsqu'il se déconnecte...

Le problème est que les utilisateur ne se déconnectent pas souvent et quitte plutôt le navigateur ou change de domaine...

En gros, pour que ma solution fonctionne, ma question est: Y a t-il un moyen de savoir si la session en cours de l'user s'est terminé ? (et pas forcément que l'user s'est déconnecter en cliquant sur déconnexion!)

Sinon y a t-il une meilleur solution que mon flag en DB ?

Merci

[benthebest]

Je viens d'avoir une autre idée, dites moi ce que vous en pensez:


1) USER1 se connecte avec le compte "TOTO"
2) Son ID SESSION est enregistré en DB
3) USER2 arrive et tente aussi de se connecter a "TOTO"
4) Le programme check si y a deja un ID SESSION ==> OUI, donc un nouvel ID SESSION est crée pour USER 2 qui vient écraser l'ancien ID SESSION de USER1
5) USER2 est connecté
6) Parallèlement, USER1, en continuant sa navigation se fait déconnecté car son ID SESSION != de celui en DB et on le prévient avec un message "Un autre user s'est connecté sur le compte TOTO, vous avez été déconnecté"

En fait, dans cette solution, c'est le dernier connecté qui a la connexion. Donc, plus de problème que USER1 ferme brutalement son navigateur sans s'être déconnecté...


Qu'en pensez-vous?? Ça tient la route non?

[Madfrix]

En fait, dans cette solution, c'est le dernier connecté qui a la connexion. Donc, plus de problème que USER1 ferme brutalement son navigateur sans s'être déconnecté...

Oui mais le user1 se reconnecte et deconnecte le user2 qui lui meme se reconnecte puis deconnecte le user1 quand arrive le user3 qui deconnecte le user1 et le user2 alors le user1 et le user2 se reconnectent...

Bref ca tient pas la route

Moi j'insererai à chaque action du user connecté un timestamp dans la base et personne ne pourrais se deconnecter le time()-timestamp < 10minutes par exemple et si un user se connecte (ie time()-timestamp > 10) alors le user1 est deconnecté

[benthebest]

Oui mais le user1 se reconnecte et deconnecte le user2 qui lui meme se reconnecte puis deconnecte le user1 quand arrive le user3 qui deconnecte le user1 et le user2 alors le user1 et le user2 se reconnectent...

Bref ca tient pas la route

Moi j'insererai à chaque action du user connecté un timestamp dans la base et personne ne pourrais se deconnecter le time()-timestamp < 10minutes par exemple et si un user se connecte (ie time()-timestamp > 10) alors le user1 est deconnecté

Attend, je comprend pas pourquoi tu dis cela, si user1 ne fait pas la démarche de se reconnecter, il ne se reconnectera pas tout seul!

Sinon, oui l'idée est bien de connecter le dernier arrivé exactement comme le fait msn messenger lorsqu'on se connecte à son compte alors qu'une autre session est ouverte sur un autre ordi par exemple....

De plus l'idée de ton timestamp oblige quelqu'un à rester connecté au minimum 10 minutes...

[Madfrix]

Attend, je comprend pas pourquoi tu dis cela, si user1 ne fait pas la démarche de se reconnecter, il ne se reconnectera pas tout seul!

Et s'ils le font ?

bref, il suffit que tu ais 2 utilisateurs qui veulent se connecter et ils n'arriveront donc jamais a se connecter plus que quelques secondes...et 2 utilisateurs sur un site web c'est vraiment pas bcp

[RunCodePhp]

Salut

Désolé pour l'incruste.

Je serais curieux de savoir le secteur d'activité, si ce n'est pas trop indiscret qui oblige à n'avoir qu'1 seule personne sur le site.
Et la cerise sur le gâteau si ce n'est pas trop abusé
Pour quelle raison ? Quelle impact y aurait il s'il venait en avoir un 2ème, un 3ème ?
C'est la 1ère fois que je vois une telle demande ... d'où cette curiosité.

Ceci dit, je partage l'avis de Madfrix, du controle sur le mot de passe + contrôle de session + une durée max (expiration) en cas de non fermeture du navigateur.


Ceci dit, peut être que le fait qu'une session soit créé, ceci pourrait aussi être un élément pour dire, ou refuser d'ouvrir/créer une seconde session.
En somme, 1 seule session est possible ou autorisé.
Pour le mettre en place ??? Je ne vois pas trop cependant.

[benthebest]

Et s'ils le font ?

bref, il suffit que tu ais 2 utilisateurs qui veulent se connecter et ils n'arriveront donc jamais a se connecter plus que quelques secondes...et 2 utilisateurs sur un site web c'est vraiment pas bcp

Je précise, c'est pas 2 utilisateurs sur le site lol ! C'est 2 utilisateurs voulant se connecter sur le MEME compte (login et mdp identique) et en meme temps!!!

En meme temps, en general chacun a son compte donc c'est sensé déjà etre un cas rare. Si ils le font il y aura de toute facon un message qui apparait en leur disant que quelqu'un d'autre s'est connecté a ce compte d'ou sa deconnexion, il finira donc bien par comprendre

C'est juste par sécurité, car si 2 personnes modifient des données simultanément, dans mon cas ça peut poser problème...


Héhé, je viens de faire un essai: essayez par exemple de vous connecter à votre compte facebook à partir de IE, puis ouvrez Firefox et faite de meme: il y a deconnexion sur IE!!

[RunCodePhp]

Je précise, c'est pas 2 utilisateurs sur le site lol ! C'est 2 utilisateurs voulant se connecter sur le MEME compte (login et mdp identique) et en meme temps!!!

Désolé, j'avais mal compris


Ceci dit, rare à mon avis font ce que tu souhaite faite, et même FaceBook.

La raison est quelque part simple : Pourquoi aurait il 2 personnes sur le même compte ?
Un compte est unique théoriquement.
Aussi, cette sécurité c'est à l'utilisateur de l'assurer, comme ne pas divulguer son login/passe, ça fait partie de ces données confidentielles.


Faut il gérer le cas d'un manque de prudence de la part de(s) l'utilisateur(s) ?
Car le fond du problème est là, non ?
Du coup, en cas de doublon avéré (connecté), qui faut il refuser ?
Le 1er ou le 2ème connecté ?
En somme, qui est l'usurpateur ?
Ne faudrait il pas bloquer/refuser les 2 ?

On peu même se dire que se serait un coup d'bol que les 2 personnes se connectent en même temps.
Mais les autres fois, est on certain que ce soit toujours la même (et la bonne) personne qui se connecte ?
Là aussi il faudrait du coup traiter le cas dans ces conditions, non ?


Pour ma part j'en ferais rien.
Une banque ou autre activité très sensible peut être, mais le reste, je ne suis pas certain que ça vaille le coup.

[Madfrix]

Désolé, j'avais mal compris

+1 moi aussi

Mais donc ca implique, que tu veux empecher un utilisateur de se connecter sur ton site via ie et ff en meme temps par exemple alors non ? Travailler peut etre avec les ip dans ce cas

[benthebest]

Le problème est que, meme si l'user ne devrait pas faire ca, si il le fait ca peut provoquer des bug donc, mieu vo prevenir que guerir

[RunCodePhp]

Le problème est que, meme si l'user ne devrait pas faire ca, si il le fait ca peut provoquer des bug donc, mieu vo prevenir que guerir

Et pourquoi le ferait il ?

Vu qu'il a accès à ces données, car c'est pour cette raison qu'il y a une identification, et bien à part fiche en l'air ces propres données, il ne devrait pas pouvoir en faire plus.

A mon sens, tu te prends la tête pour pas grand chose, et de plus, du moins à mon sens, ceci n'est pas de ton ressort, mais celui de l'utilisateur.

Toujours est il que ça ne devrait pas provoquer de bug, sinon, c'est ton code qui va pas.
C'est donc en amont qui ne va pas.

Ou alors, en admettant que cela concerne un espace admin (backend), et bien c'est que le partenaire, associé (que sais je) à péter un durite

[Madfrix]

au pire dans la base rajouter un champs lock (true, false) qui locke la table avant de faire toutes les requetes puis le delocke à la fin ne permettant pas l'execution de requetes concurrentes si ton bug vient de là

[ascito]

Bon, tu ne nous a pas donné le vrai pourquoi, mais c'est bien comme cela...

Moi j'ai imaginé un couple ( login / mdp ), disponible pour plusieurs personnes.

Je me suis dits : il y a deux cas de figure

1 ) Tu as réellement besoin de limiter des intrusions..
2 ) Tu cherches à savoir combien de personnes différentes se connectent avec le même login et mot de passe à un instant donnée

1 ) Dans le premier cas, simple, tu contact les personnes concernées et tu change les mdp


2 ) Dans le second cas, il te faut créer un journal d'accès à la base :

A chaque fois qu'une personne se connecte, tu as une table dédié, qui incrémente ( idAutoI , IPbecan , IdUtilisateur , idNouveauUtilisateur , DATE),

Le idNouveauUtilisateur, représente un id Unique de connexion, il doit être unique, et représente la possibilité d'avoir plusieurs utilisateurs utilisant la même adresse IP, avec le même couple login / mdp

Donc quand une personne essai de se connecter pour la première fois, et que tu l'autorise à accéder au contenu, tu lui donnes un id Spécial, qui ne corresponds à rien d'autre , qu'une suite alpha numérique aléatoire ( aern88), mais que tu faits correspondre avec des données : IPbecan , IdUtilisateur

Cela te permettra déjà de savoir si vraiment plusieurs personnes se connectent en même temps.

Ensuite tu peux lancer un script AJAX sur ton fichier natif php, celon tes besoins de vérification toutes les heures, minutes , etc ..... qui vérifie que les couples IPbecan / IdUtilisateur / idNouveauUtilisateur sont dispos...

bon courage

[benthebest]

Merci pour vos reponses

Le problème est que j'ai vraiment besoin de bloqué la connexion simultané au meme compte car mon applic utilise un mapage DB / SESSION de données (pour des questions de performance car ca m'évite de nombreuses connexion avec la DB) qui se doivent de garder leur intégrité (donnée SESSIONS == donné DB).

Or si user1 se connecte et modifie les données et user2 se connecte au meme compte en meme temps et modifie aussi les meme données, ben ça fou la pagaille!

En fait j'aimerai bien revenir a la premiere solution toute simple qui etait de mettre un flag au niveau du compte lorsque un user s'y connecte de facon a ce que si un autre essaye, il ne peut pas.

En fait, comme c'est un cas rare (mais que je me dois de traiter malgrè tout) ca ne me dérange pas de bloquer l'autre user pendant X minutes le temps que la session se termine.

Mais mon problème est dans l'implémentation de ceci... Prenons un cas de figure:

1) monsieurX se connecte au compte TOTO ==> flag sur le compte TOTO
2) monsieurY tente de se connecter ==> il est bloqué par le flag, normal !
3) 10 minutes plus tard, monsieurX ferme son navigateur ou va sur un autre site...
4) monsieurY essaye de se re-connecter à TOTO (il devrait logiquement y avoir droit puisque monsieurX est parti)!! Problème la session de monsieurX est toujours active et le flag est toujours la !

==> Vous comprenez alors que mon problème est de faire en sorte que, au bout d'un certain temps d'inactivité de monsieurX (10 minutes par ex) et bien je veux détruire sa session et autoriser monsieurY à se connecter sur le compte TOTO


Donc je résume, voici mes questions pour parvenir à cela :

Comment savoir que monsieurX est actif sur sa session, sachant qu'à la limite je peux enregistrer en DB son id_session en meme tps que la mise à jour du flag lors de sa connection comme ça je peux checker si cet id_session est toujours actif lors d'une nouvelle connection ultérieure (si il y a un moyen de savoir que la session d'id XXXXXXXXX est active ou pas ?!?) ?
Car l'idée c'est que quand monsieurY tente de se connecter a TOTO, il voit qu'il y a toujours XXXXXXX en DB, donc si on peut checker que ça fait 10 minutes que monsieurX n'a pas d'activité sur cette session, ben on autorise monsieurY a se connecter et on (peut??) détruire "à distance" (je dis à distance pk c la connection de monsieurY qui doit détruire la session de monsieurX) la session XXXXXXX

Et au fait, (je suis naze en session) mais comment fait t-on pour donner une durée de vie à une session, c'est à dire, si par exemple je donne 10 minutes par session, et bien je veux que le compte à rebourd des 10 minutes commence à partir du moment où l'utilisateur est inactif, c'est possible ça aussi?

(désolé pour la quantité!!)

[Madfrix]

==> Vous comprenez alors que mon problème est de faire en sorte que, au bout d'un certain temps d'inactivité de monsieurX (10 minutes par ex) et bien je veux détruire sa session et autoriser monsieurY à se connecter sur le compte TOTO

Il me semble que je te l'avais déjà proposé hier

Oui mais le user1 se reconnecte et deconnecte le user2 qui lui meme se reconnecte puis deconnecte le user1 quand arrive le user3 qui deconnecte le user1 et le user2 alors le user1 et le user2 se reconnectent...

Bref ca tient pas la route

Moi j'insererai à chaque action du user connecté un timestamp dans la base et personne ne pourrais se deconnecter le time()-timestamp < 10minutes par exemple et si un user se connecte (ie time()-timestamp > 10) alors le user1 est deconnecté

la méthode des timestamp en base ne te convient pas ?

[benthebest]

Mais n'est-ce pas un peu lourd le fait de devoir mettre à jour la base à chaque action ??

[Madfrix]

Cela fait juste un update d'un seul champs, alors si certes c'est plus long que de ne rien faire c'est largement raisonable surtout qu'il y aura qu'un utilisateur sur ton site à chaque fois alors....

[RunCodePhp]

Or si user1 se connecte et modifie les données et user2 se connecte au meme compte en meme temps et modifie aussi les meme données, ben ça fou la pagaille!

C'est ça qui est bizarre.
Faudrait peut être voir à ce niveau, et corriger au besoin.

Pour ma part, ça ne devrait pas causer de problème.
Si 2 personnes se connectent en même temps, le seul truc qui normalement change, c'est les entêtes liés au navigateur, et éventuellement l'adresse IP.
En quoi ceci pourrait mettre "la pagaille" sur un site ?


En faite, je crains que la sur-couche de code que tu tente de faire s'apparenterait plus à un scotch qu'à véritablement résoudre le problème.
Mais pourquoi pas, évidemment.


Au niveau des sessions, de la manière dont tout ça est géré, du moins par défaut, ça tient sur des directives du php.ini
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

Il y a donc un délai : 1440 secondes (soit 24 minutes)
Ensuite, leur destruction (physiquement si on peu dire) est un peu aléatoire, ça dépend de gc_probability et de gc_divisor.
En somme, ça tient sur des probabilités.


Mais n'empêche que leur date d'expiration elle est théoriquement connue.
Il faudrait voir de ton coté comment tes sessions sont gérées.

Donc même si la donnée est dans la Bdd (ou fichier encore présent), il y a moyen de savoir si le délai est expiré ou pas, ne serait ce qu'au niveau du cookie, fonction : session_get_cookie_params().

Pour ce qui est de savoir très exactement si la session est active ou pas, et bien il n'y a pas grand chose, à part justement ce délai d'expiration.
Sa réactivation (le délai repart à 0) est faite uniquement si la personne lance une requête HTTP au serveur, et bien sûr, avant le délai d'expiration.
Sinon, une nouvelle session sera accordée.

[benthebest]

Encore merci pour vos réponse

Ça me semble vraiment compliqué tout ça...


Et pourquoi au lieu de s'embêter avec le calcul du temps d'inactivité ou autre, on ne vérifierai pas l'existence du cookie qui a été crée sur le serveur pour la session !!

Je m'explique: j'ai lu que lorsqu'une session se créée, ça crée un fichier cookie sur le serveur dans un répertoire /tmp je crois.

Et lorsque la session n'existe plus, bien ce fichier disparait...

Donc mon idée est d'enregistrer le path complet de ce fichier cookie en DB lors de la 1ère connexion et, si il y a une autre tentative de connexion, on check si ce cookie existe toujours, si oui ==> accès refusé, si non accès autorisé !


Ça c'est bon, non?

[Madfrix]

Ça c'est bon, non?

Non car dans l'absolu, si l'utilisateur part jouer au foot sans fermer son navigateur, ta session ne se referme pas. idem s'il ferme son onglet sans fermer son navigateur