Forum d'entraide PHPFrance

J'utilise les sessions pour gérer les pages accessibles seulement aux utilisateurs qui sont inscrits.
Mon service est payant et je ne veux pas qu'une seule personne s'inscrive et partage son identifiant. Je ne peux pas complètement empêcher ça, mais je veux au moins empêcher que 2 personnes se connectent avec le même identifiant en même temps. Je ne peux pas utiliser l'IP car je veux aussi empêcher que 2 postes sur la même IP se connectent en même temps.

Sur les forums j'ai trouvé 2 solutions qui ne me vont pas :

• Ejecter le 1er utilisateur connecté quand un 2eme se connecte avec le même identifiant. Je veux empêcher le 2ème de se connecter.
• Enregistrer en base quand un utilisateur se connecte et quand il se déconnecte. Le problème est que rare sont ceux qui se déconnectent proprement, et alors quand il revient la base le voit toujours connecté. Pour pallier à ça, on peut sauver un timestamp à chaque fois qu'il y a une action, et considérer que si la dernière action a plus de 10min, on l'autorise à se reconnecter car la connexion est trop vieille. Mais si l'utilisateur veut se reconnecter moins de 10min après on aura toujours le même problème.

Est-ce que quelqu'un connait une solution pour empêcher un 2ème utilisateur de se connecter simultanément avec le même compte ?
(Je précise que c'est un comportement que j'ai déjà vu dans au moins un site, donc c'est possible)

Bonjour,

Tu peux stocker l'adresse ip liée à un identifiant et la date/heure d'utilisation de cette IP pour cet identifiant dans la table des utilisateurs et garder ces information en session.
Tu peux alors contrôler que le changement IP : entre la session, la table et l'ip du client.

Je n'ai peut-être pas compris ta réponse, mais comme dit dans le sujet "je veux aussi empêcher que 2 postes sur la même IP se connectent en même temps".

Là c'est plus problématique car il te faut identifier le poste client, et c'est falsifiable...
Mais dans l'optique tu peux enregistrer le USER-AGENT pour identifier le poste ou autre information du style.

Si c'est difficile à falsifier, ça peut être une sécurité suffisante pour le type d'utilisateurs. Ce n'est pas un site de banque.

Le USER-AGENT permet d'identifier un poste ?
Si plusieurs ordinateurs dans une entreprise, ou dans une école, ont la même configuration (machine/navigateur/IP) le USER-AGENT sera pareil non ?

Si on sait configurer son navigateur on peut falsifier aisément ces informations.
En effet, si les postes sont identiques le user-agent doit être le même.

Le plus simple ne serait-il pas de bloquer au niveau du script de connexion si une entrée existe déjà dans la bdd ?
Avec un timeout de présence pour supprimer les entrées qui datent.

Car de manière une session c'est identifié par un SSID qui ne peut sans bidouille être partagé par deux ordinateurs.
Là aussi c'est falsifiable mais bon... Si comme tu le dis ce n'est pas à destination d'une banque je pense que la solution peut être suffisante.

La solution que tu proposes c'est le 2eme point dans le post original.
Je refuse la connexion s'il y a déjà une connexion pas assez vieille. Le problème c'est que le timestamp pour considérer une connexion "trop vieille" doit être :
- petit pour permettre à quelqu'un qui a fermé son navigateur sans faire exprès, de se reconnecter sans attendre
- long pour pouvoir souffler entre 2 actions sans se faire éjecter de sa propre session

Ça ne me parait donc pas être une bonne solution.

Est-ce qu'on peut imaginer un moyen pour que quand une personne se connecte, et que dans la base il existe déjà une connexion pas trop vieille pour ce compte, le serveur vérifie si le mec est parti ou s'il utilise toujours le site ?

Le seul moyen que je vois, c'est de générer 1 code unique à la connexion et le rajouter dans les conditions d'authentification. Tu le stockes en base ou dans un cookie et tu vérifies sur chaque page s'il correspond bien au dernier code.
Si quelqu'un se connecte après, ça fait sauter la session de l'autre. Tu log le tout et t'as un détecteur de "partageurs de sessions"

oui mais alors bon ça c'est le premier point du post original...
La consigne qu'on m'a donné c'est pas d'éjecter le premier connecté quand un deuxième arrive, c'est d'empêcher que le 2ème se connecte.

Qui t'a donné cette consigne et pourquoi?

Qui t'a donné cette consigne et pourquoi?

C'est dans le cahier des charges, j'ai pas vraiment le choix.
La raison est compréhensible, quand tu utilises le site t'as pas envie de te faire sortir, même si tu as donné tes identifiants à un copain. Tu veux plutôt que ton copain ne puisse pas se connecter en même temps que toi. Et s'il se trouve que quelqu'un a volé tes identifiants, et s'est connecté avant toi et t'empêche donc de te connecter, tu peux toujours changer ton mot de passe.

Oui enfin si tu partages tes logs avec un ami alors que c'est interdit, il faut pas se plaindre
Et puis, si le principe est de bloquer la connexion c'est bien pour détecter les tricheurs et donc les bannir non?

Bref, je ne vois pas de solution fiable surtout si tu refuses de te baser sur la déconnexion du membre ou un délai minimum (ce que je comprends).

identifiant unique => SID : c'est uen première chose

enregistrement dans une table (disont connexions) idmembre + sid + timestamp

lors de l'utilisation du formulaire de connexion tu regarde s'il existe un membre dans cette table.
particularité : il faut que ton timestamp soit inférieur à la date actuelle moins la durée de vie d'une session.

lorsque tu ferme ton navigateur, et que tu garde tes cookie ta session est toujours valide (car basé sur la présence du cookie).
enfin si tu utilise les cookies pour la gestion des session (voir conf de php).


tu peu aussi imaginer une requête ajax qui vient utiliser un fichier php juste pour maintenir la session ouverte et ainsi garder le premier connecté toujours connecté.

tu peux imaginer d'utiliser les web socket pour faire du push vers le clietn si cela ne répond par du nettoie la table de connexion (a faire à la déconnexion aussi). ceci est à prévoir avec une tache qui se déclenche régulièrement.
tu peux aussi blinder coté SGBD avec un trigger, une procédure qui fait le ménage et sera appelée périodiquement (par exemple calé sur la durée de vie d'une session).

Dans tous les cas :
- une identification unique est peu probable en se basant sur le info fournie par le navigateur (car facilement falsifiable).
- A toi de prévoir le cas où l'on laisse la page ouverte toute la nuit (genre pc allumé au bureau et verra demain) et lorsque l'on revient soit la première action déconnecte (avec un beau message d'erreur time out => reco), soit tu applique ma solution du pooling pour garder la session ouverte.

quoiqu'il arrive tu aura toujours la possibilité d'emmerder quelqu'un.
Lais te baser sur le SID (et l'ip) est une bonne solution car peux gens s’amuse à refiler un cookie, et comme tu l'indique tu ne fait pas un truc pour la nasa

Attention au stockage de l'ip c'est soumis a réglementation


@+

lorsque tu ferme ton navigateur, et que tu garde tes cookie ta session est toujours valide (car basé sur la présence du cookie).
enfin si tu utilise les cookies pour la gestion des session (voir conf de php).

Dans php.ini j'ai session.cookie_lifetime = 0 donc quand l'utilisateur ferme le navigateur, le cookie avec son SID est supprimé.
Donc quand il redémarre son navigateur et essaie de se connecter sur son compte, pas moyen de voir si c'est lui-meme ou si c'est quelqu'un d'autre qui a la meme IP et le meme user-agent.
Je peux tenir à jour un timestamp pour considérer quelqu'un qui ne fait plus rien depuis 10min, comme déconnecté.
Mais si le mec veut se reconnecter après avoir redémarré son navigateur depuis moins de 10min... j'ai rien pour voir que c'est toujours lui ou un autre.

Sauf si je garde un 2eme cookie qui lui est persistant, avec dedans le login et le timestamp de la dernière activité.
Il y a toujours des limites : si il veut se reconnecter avec un autre navigateur ou qu'il refuse les cookies, il sera traité comme un 2eme utilisateur voulant se connecter sur le compte déjà connecté. Mais ça réduit quand même bien les possibilités de refuser un utilisateur de bonne foi.

Qu'en pensez-vous ?

c'est une solution.

Perso si la durée de vie c'est la fermeture du navigateur pas de quartier, il ferme de navigateur session close, le sid ne sera pas repris => c'est une nouvelle session. Avec ce que j'ai mis plus haut (donc si tu utilise le sid comme identifiant) ce n'est pas un problème il a juste a ré authentifier, par contre effectivement tu peux être emmerdé via l'ip.

ceci dit l'ip n'est pas une donnée fiable (va tu réussir à passer les proxy ?).


@+