N'autoriser l'accès d'un compte sur mon site que d'une seule personne à la fois

Oui mais elle se refermera bien un jour et donc ce fichier disparaitra en même temps!

Encore une fois, je vous est spécifié que ce n'est pas très grave dans la mesure où c'est un cas rare, moi ce qui m'importe le plus c'est que 2 sessions d'un même compte ne se télescopent pas...

Dans le pire des cas, un user proche du 1er (puisqu'il lui a donné ses identifiants) ne pourra pas se connecter tant que l'autre n'a pas fermé son navigateur et franchement dans mon cas, c'est pas catastrophique...

A priori, dans ces cas la, c'est bon?

Citation:

---

Envoyé par Madfrix

Non car dans l'absolu

---

+1

Sans compter que si tu ne fais rien de spécial de ton coté, tu ne sais pas à qui appartient le cookie de session.

De plus, et comme je l'expliquais plus haut, la suppression des sessions, qui par défaut sont des fichiers (dans le /tmp comme tu l'as dis), ils ne sont pas immédiatement supprimés dès leur date expirée, mais par un autre processus du système, donc plus tard.
Tout est une question de probabilité.

Pour gérer tout ça au mieux, l'idéal serait de gérer les sessions dans la Bdd, c'est d'ailleurs très courant, car justement ça permet plus de souplesse, sans compter que ça les sécurisent mieux.


D'ailleurs, je viens de voir un tuto la dessus :
Utiliser une base de données pour sécuriser vos sessions
Par contre, il date un peu (2006), faudra pas prendre tout ça tel quel, mais t'en inspirer.
Mais en cherchant mieux sur le Net, il y a peut être moyen d'avoir une classe Php plus à jour.
Et pourquoi pas jeter un oeil dans des Soft Open Source, il doit avoir ce genre de solutions.

Citation:

---

Envoyé par RunCodePhp

+1

Sans compter que si tu ne fais rien de spécial de ton coté, tu ne sais pas à qui appartient le cookie de session.

---

Tu peux etre plus explicite?

Citation:

---

De plus, et comme je l'expliquais plus haut, la suppression des sessions, qui par défaut sont des fichiers (dans le /tmp comme tu l'as dis), ils ne sont pas immédiatement supprimés dès leur date expirée, mais par un autre processus du système, donc plus tard.

---

Je repète ce n'est pas très important dans mon cas...

Citation:

---

Pour gérer tout ça au mieux, l'idéal serait de gérer les sessions dans la Bdd, c'est d'ailleurs très courant, car justement ça permet plus de souplesse, sans compter que ça les sécurisent mieux.

---

Oui mais moi j'ai besoin de performance et les aller/retour avec la DB c'est pas ce qui a de mieu dans mon cas...

Serieusement, je ne vois pas en quoi ma solution pose problème??

Il y a un moyen de recupérer a la connexion le chemin du fichier cookie , je le met en DB et je check son existence si il y a une autre tentative de connexion...

Pkoi faire plus compliquer?? :D

Citation:

---

Oui mais moi j'ai besoin de performance et les aller/retour avec la DB c'est pas ce qui a de mieu dans mon cas...
Il y a un moyen de recupérer a la connexion le chemin du fichier cookie , je le met en DB et je check son existence si il y a une autre tentative de connexion...

Pkoi faire plus compliquer?? :D

---

Je n'ai jamais parlé d'aller/retour, juste que les sessions soient dans la Bdd.

Tu ne pourras pas récupérer le chemin du cookie, car c'est du coté client.
C'est le poste client qui transmet les infos du cookie dans la requête HTTP.
Le seul truc que tu pourras avoir, c'est exploiter le cookie, comme lui donner comme valeur l'ID de session lors de sa création.
Il faut au moins que les 2 ait une info commune, l'ID de session est certainement l'élément le plus pertinent.

Ce serait avec les fonctions comme session_set_cookie_params() et session_get_cookie_params().
Vois aussi du coté de session_set_save_handler(), la doc te donne des explications et des exemples de codes sur comment sont gérer les sessions/cookies.

Je ne sais pas si ta solution fonctionnerait, mais si tu le pense, et bien fait le, fais des essais.

Bonjour et bon week-end,
Peut-étre quelques afirmations techniques aideraient le débat.
Le seul fait de faire session_start(); provoque une démarche complexe mais précise:

Citation:

---

le serveur demande au client s'il a un cookies de session pour le domaine du site. (on ne parle pas un cookies de données bien sur)
si le client renvoie l'ID de sa session, par exemple "ajhkjhsqdksj158745jhsqhjh" le serveur va lire dans SON répertoire de sessions le fichier ajhkjhsqdksj158745jhsqhjh.txt, et va contrôler que celui-ci est plus récent que 10 minutes (en général) si oui, alors il charge toutes les valeurs de sessions qui s'y trouvent !

---

Citation:

---

si le client ne renvoit pas d'ID le serveur lui crée un cookies de session et y place une nouvelle idée de session. Il se crée un fichier vide

---

Citation:

---

si le client avait bien renvoyé son ID, mais que le fichier correspondant a une date dépassée le serveur lui REcrée un cookies de session et y place une nouvelle idée de session. Il se crée un fichier vide

---

Les ruptures sont :
coté serveur si un fichier de session n'a pas été solicité aprés 10 minutes il est détruit sans que nous n'ayons rien a faire.

coté client la fermeture du navigateur (pas des onglets) supprime tous les cookies de session.

Et notez qu'en aucun cas un client présent sur un site n'est visible par PHP tant qu'il ne le solicites pas , ou par javascript ou en cliquant un lien !
Je ne parles pas AJAX car en fait c'est bien javascript qui interpelle PHP

Merci de vos réponses

Petite précision, quand je parle de contrôler l'existence du fichier cookie, je parle bien sur du fichier cookie de SESSION et donc, qui se trouve du coté serveur..

Pour revenir à ce que dis mauriser, tu confirmes donc par la même qu'il suffirai que je teste l'existence du fichier ajhkjhsqdksj158745jhsqhjh.txt lors d'une tentative de connexion pour tester si la session est toujours active et autoriser ou pas la connexion, on est d'accord?

Bon j'ai un ptit problème ;)

Je viens de vérifier quelque chose, bien que la session ai été détruite, le fichier session sur mon serveur ne semble pas se détruire...

Alors je me suis dis "bon ben attends un peu"...

Mais je me rends compte qu'il garde un fichier session d'une session que j'ai ouverte hier après-midi!

Il en met du temps à détruire se fichier!!


Quelqu'un a une idée pour accélérer ceci (style destruction du fichier pas plus tard qu'une heure après fermeture du navigateur...) ?

Oui absolumnt normal, mais je te ferais remarqué que le ménage de ton répertoire temp sur ton micro c'est pareil !
Alors ça dépends des serveur qui "purgent" tous les xxxx mais ça on s'en moque puisque le serveur ne transmets plus les données, et que de toute façon la clé pour l'ouvrir n' est plus sur ton micro :roll:

Je viens de checker un truc dans mon php.ini:

session.gc_divisor = 1000 8O

C'est pas abusé comme valeur??

Par défaut il me semble que c'est = 100, je trouve que 1% c'est déjà pas beaucoup alors 1/1000 c'est pas grand chose!

Qu'est ce vous en pensez? Ceci explique cela? Je remets à 100 ?

Ohla !! pas touche il faudrait lire la doc, c'est un calcul tordu,
qui ne s'applique pas comme tu crois. gardes

session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

Citation:

---

session.gc_divisor en conjonction avec session.gc_probability définit la probabilité que la routine gc (garbage collection) soit démarrée à chaque début de session. La probabilité est calculée en utilisant gc_probability/gc_divisor, par exemple 1/100 signifie qu'il y a 1 % de chance pour que la routine gc démarre à chaque requête. La valeur par défaut est 100.

---

Moi je laisses les 1000 par default contrairement a la doc, c'est ce qu'installe par default les easyphp et autres 1/1000 ça suffit non :roll:

Mais quel est le problème? Au pire , en mettant à 100 ben j'augmente la fréquence de purge des fichiers sessions obsolètes! (j'ai bien lu la doc :mrgreen:)

Bon sinon voici mon plan:

A la connexion d'un user:
Id session en DB = "" -> ok pour connexion
Sinon
check existence fichier session:
existe pas -> ok pour connexion
Sinon
check la date de dernière modification du fichier session:
> 1h -> je le supprime + ok pour connexion
Sinon
pas ok pour connexion

Voila mon algo, qu'en dites-vous?

A te lire j'ais l'impression que tu reviens a ton idée de départ, refaire a la main ce qu'un navigateur qui rencontre un serveur font tout seuls comme des grands.

Relis ma premiére intervention, je croyais avoir été claire et rassurante :(

Euh désolé mauriser mais j'ai pas bien compris de quoi parles-tu?

Bon on récaptiule tout pour être plus claire:

J'essaye de trouver une solution qui me convient et simple à mettre en place de blocage d'accès à un compte utilisateur par plus d'une personne en même temps.

Jusque là on est ok.


Au file de la discussion, je me rends compte qu'un simple test d'existence du fichier session sur le serveur peut me dire si oui ou non la session entrée en DB lors de la connexion du 1er user est toujours présente (puisque en théorie ne réside sur le serveur que les fichiers dont les sessions sont encore active à + 1440 secondes).

Le seul hic c'est que PHP met plus ou moins de temps à virer ces fichiers sessions lorsqu'ils deviennent obsolètes (cf le fameux coefficient gc_probability/gc_divisor)...

Donc, une idée (que j'ai vu d'ailleurs sur le net) est de checker la date de la dernière modification de ce fichier session afin de voir si elle est inactive ou pas (si ce fichier n'a pas été touché depuis plus d'une heure, on peut considérer que la session est inactive donc obsolète).

En quoi mauriser je reviens à ma solution de départ? (et puis laquelle parce que y en a eu plusieurs...:lol:)

Slt

Une session php est enregistrée sur le serveur distant et mise en cache sur le navigateur de l'utilisateur.
Par conséquent, il est impossible de savoir si une session est déjà ouverte sur un navigateur différent du sien.
Chaque utilisateur crée sa propre session au moment de l'dentification et dispose des variables utiles depuis son propre navigateur.

Parrallélement, même si tu enregistres sur db un id de session créé pour le premier utilisateur (dixit ta suggestion d'écraser l'id par un nouvel id), tu ne pourras pas savoir si cette session etait bien en cours ou détruite depuis des lunes.
Et ceci, si un deuxiéme utilisateur se connecte avec le même login.
La seule chose qu'a fait ta db, c'est enregistrer une simple variable.

N'oublie pas que, même si l'id de session est modifié dans ta bd, le premier utilisateur ne sera pas déconnecté.
Pourquoi ?
Puisqu'il utilise les variables mises en cache dans son navigateur, et non pas celles fournies par ta db.
Enfin... sauf si dans chaque page de ton applic tu relances une requête de vérification d'id de session.
==> Hum...et c'est justement pour éviter ses requêtes répétitives et inutiles que le système des sessions a été élaboré.

Et enfin, il y a une chose que je ne comprends pas.
Si 2 utilisateurs différents ont les mêmes droits, c'est à dire de pouvoir modifier à souhait tel ou tel contenu, je ne vois pas où est le probléme même s'ils sont connectés en simultannés.
Ils ont les droits, ils ont les droits même d'écraser le contenu de l'autre, et pourquoi pas en même temps ?.;)

Citation:

---

Envoyé par benthebest

Je C'est 2 utilisateurs voulant se connecter sur le MEME compte (login et mdp identique) et en meme temps!!!

---

Mot de passe et login identique, plutôt étrange comme philosophie quand on parle de sécurité. ;)

Bon je vais faire des tests et je vous donne les résultats!

En attendant, quelqu'un sait pourquoi je n'arrive pas à tester l'existence du fichier par:

Code:

---

1 2 3 4 5 6 7

if(file_exists("/var/php/session/sess_fzee5645f4z654z6f565az")) { ... } else echo "Erreur";

---

Il me dit "Erreur" alors que file_exists ne plante pas dans un fichier situé dans mon httpdocs ? Pourtant je suis en dédié et safe_mode n'est pas activé...

Citation:

---

Parrallélement, même si tu enregistres sur db un id de session créé pour le premier utilisateur (dixit ta suggestion d'écraser l'id par un nouvel id), tu ne pourras pas savoir si cette session etait bien en cours ou détruite depuis des lunes.

---

Non, benthebest à trouver le moyen de le savoir avec la date de dernière mise à jour du fichier.
Donc même si le serveur n'a pas détruit (physiquement, si on peu dire) le fichier, ce n'est pas un problème.

Cependant, se contenter de voir si la date de dernière mise à jour est encore valide ou pas ne sera pas suffisant, il te faut un info : l'ID du user pour chaque session.
Il faudrait donc que la session contienne cette info.
Ensuite, il faudrait lire le contenu des fichiers de sessions, les dé-sérialiser sera nécessaire, fonction unserialize().
Théoriquement, tout ceci dans la boucle où tu feras le parcourt des fichiers de sessions.

[ En 1er, on aura récupéré l'ID du user qui tente de s'identifier (login/pass) ]

-> S'il n'y a pas de user_id (n'existe pas), c'est un visiteur lambda, ou un robot (un bot), etc ... : On continu, on passe au suivant.
-> S'il y a un user_id ET que les 2 IDs sont identiques ET que le délai d'expiration (10 min) n'est pas écoulé -> "Désolé mon p'tit père, va falloir revenir plus tard".
SINON : Ok, c'est bon.

Théoriquement ça devrait le faire.

Citation:

---

Il me dit "Erreur" alors que file_exists ne plante pas dans un fichier situé dans mon httpdocs ? Pourtant je suis en dédié et safe_mode n'est pas activé...

---

C'est peut être un problème de droit.

Il faudrait que tu te crée un répertoire dans ton propre espace d'hébergement, du moins, dans un répertoire ou tu auras les droits suffisants.
Faut éviter de le placer dans le serveur Web, pour des raisons de sécurité.
Faudra surement le protéger quand même par un .htaccess.
Après suffit de définir le chemin avec session.save_path, dans .htaccess (ou php.ini si tu peux) du serveur Web (du domaine en question).

Bonjour, et désolée de me lever si tard :oops:

Allez je plaisante.
Alors je t'explique un autre aspect des choses. Aspect trés technique.

1er aspect les fichiers
Je n' avais pas remarqué que tu parlais de local mais la tu ne peux tester aucune stratégie "fichier de session" :nono:

C'est bien la seule chose que tu ne peut faire car tu n'est pas sur un UNIX ou autre serveur Apache, mais sur un windows XXX alors tes dates n'ont pas les caractéristiques ==> dates de dernier accès aux fichiers (atime).

Citation:

---

La FAT de Windows ne le fait pas, il te faudra donc trouver un autre système pour gérer les sessions qui ont expiré. bien que depuis PHP 4.2.3, on utilise mtime (date de modification) au lieu de atime.

---

2em aspect les Chemins

Autre point bien plus important, tu peux "tricher" sur un micro et aller chercher
c:\machin\tmp\ OK mais pas sur un serveur , or TOUT les serveurs sérieux placent leur fichiers de session AVANT la racine du site et donc PHP ne dispose d'aucun moyen de les lire lui même
Sur un de mes serveur dédié, le temp (qui bien sur s'appelle "xkkhxkjhx__1"
est sur le dédié mais dans une autre zone que celle du site !
C' est bien plus important si nous parlons sécuritée, que de savoir si les fichiers sont purgés oui ou non

Ces deux point devraient mieux te faire percevoir en quoi (sans vouloir te blesser) je crois que tu fais fausse route.

Citation:

---

Envoyé par mauriser

C' est bien plus important si nous parlons sécuritée, que de savoir si les fichiers sont purgés oui ou non

---

On peu le définir, Php donne toute la liberté de placer ses session où on veut, et ils seront purgés comme prévu.
Pour la sécurité, il suffit de ne pas les placer dans le serveur Web (dans le www en général) + un .htaccess et c'est bon.
C'est la directive : session.save_path

On peu même les stockés dans une Bdd, tout en profitant des purges automatique. C'est juste un peu particulier.

Citation:

---

C'est bien la seule chose que tu ne peut faire car tu n'est pas sur un UNIX ou autre serveur Apache, mais sur un windows XXX alors tes dates n'ont pas les caractéristiques ==> dates de dernier accès aux fichiers (atime).

---

Non, je viens même de faire un essai sur XP, la date de dernière mise à jour est récupérée par la fonction fileatime().
En FAT ça marchera peut être pas, mais sauf erreur ça fait belle lurette que Windows n'est plus en FAT mais en NTFS. C'est plus le même système de fichiers.

Citation:

---

Je n' avais pas remarqué que tu parlais de local

---

Il fait surement des essais sur Windows, chez lui (comme beaucoup), mais avec un chemin comme ceci : /var/php/session/sess_fzee5645f4z654z6f565az, là, ça ressemble à du Linux.
A mon sens son serveur (distant) est sous Linux.
Donc ça marchera de toute façon.

Citation:

---

Envoyé par mauriser

Ces deux point devraient mieux te faire percevoir en quoi (sans vouloir te blesser) je crois que tu fais fausse route.

---

As tu déjà essayé et remarqué ce que tu décrit ?


Pour ma part, il pourra mettre en place son truc, sans trop prise de tête.
Au départ j'avais du mal à le concevoir, mais maintenant, après avoir fait un peu le tour de la question, je ne vois pas qu'est ce qu'il pourrait l'en empêcher.

Citation:

---

Envoyé par RunCodePhp

As tu déjà essayé et remarqué ce que tu décrit ?

---

Oui bien sur , en particulier j'ais parlé des fichiers, pour rappeler que nous étions sous windows. Mais je sais que FAT<> NTFS oui et même avec un
win95 si ça existe encore ce que j'ais dit était corrigé dans les PHP >4 indépendament de l'OS.

Pour l'emplacement les WAMP et EasyPhp derniéres versions mettent les sessions (si on n,e change rien, dans documents and setting ....... temp !

Pourquoi poses tu la question :( tu croyais que j'écrivais par intuition :nono:

Citation:

---

Envoyé par mauriser

tu croyais que j'écrivais par intuition :nono:

---

Désolé, mais oui, parce que tu oubli que Php permet de faire ce qu'on veut.

Ca fait au moins 4 fois que je dis explicitement qu'on peu placer ces fichiers de session où on veut, que ce soit sur Windows ou Linux.
Pourquoi alors dit tu que ça risque de causer un problème ?
Ce n'est pas, ou plus un problème (idem pour le système de fichier) ;)

Il n'y a que des solutions, elles existent, il n'y a pas d'raison. ;)