Discussion :

[benthebest]

RunCodePhp je t'aime, on parle le même langage!!

Bon trève de baliverne...


mauriser, qui t'as dit que j'étais sous windows?? Mon serveur dédié est sous CentOS (linux presque comme Red Hat pour ceux qui connaissent po )

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.

Bien sur héhé !! Dailleurs voici comment j'ai vu la chose simplement: j'ai une table user dans laquelle je met à jour un champs 'last_id_session' représentant l'id_session du dernier user qui se connecte à son compte

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).

Je teste et vous tiens au courant

PS:

Au départ j'avais du mal à le concevoir, mais maintenant, après avoir fait un le tour de la question, je ne vois pas qu'est ce qu'il pourrait l'en empêcher.

J'ai enfin l'impression d'être moins seul tout à coup

[RunCodePhp]

Bien sur héhé !! Dailleurs voici comment j'ai vu la chose simplement: j'ai une table user dans laquelle je met à jour un champs 'last_id_session' représentant l'id_session du dernier user qui se connecte à son compte

Il n'y a même pas besoin d'enregistrer l'ID de session.
D'ailleurs, tu te focalise trop sur cet ID de session, ce n'est pas le vrai problème.

Tu oubli que les 2 IDs de sessions seront obligatoirement différents. Tu ne peux pas te reposer sur les IDs.

C'est plus simple que ça en faite, relis se que j'ai dis quelque post avant.
Tout repose sur le fait que les sessions contiennent ou pas l'ID du user.
Si une session risque de contenir 2 fois le même ID de user -> risque doublon
On s'en fiche (complètement) de l'ID de session.

Pour lire le contenu d'un fichier de session, il y a une fonction toute faite : unserialize().

Tout ça se résume en 3 opérations :
1/ Lorsqu'un user se logue, on récupère son ID dans la Bdd (mais on ne l'identifie pas encore)
2/ On parcourt chaque fichier de sessions, on dé-sérialise, on vérifie la présence ou pas du ID user. (boucle)
3/ On vérifie la concordence entre les 2 IDs des users (celle récupérée dans la Bdd et celle du fichier) ET la date de dernière mise à jours (délai expiré ou pas).

Selon le cas, on identifie ou pas la personne.
Il y a même pas lieu de toucher à ta Bdd


A coté de ça, si tu gérais tes session dans la Bdd, et non dans des fichiers, la vérification de l'existence ou non du user se résumerait à faire 1 seule requête. Ca serait plus rapide à mon avis.
Ca évite de parcourir tous les fichiers de sessions.

Gérer les sessions dans la Bdd est un peu complexe, mais ça serait pas mal dans ton cas.
Mais c'est pas obligatoire.

[benthebest]

ok, reprenons pas à pas ce que tu as dis:

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.

Dans mon cas, nullement besoin de faire une boucle pour de deserialiser et lire chaque fichiers session!!!

Je reprends mon process, en sachant que j'ai une table user contenant entre autres, un id user login mdp crypté et un champs last_id_session

L'user1 se connect avec son user/mdp (on va dire lulu/12345)
Je check si last_id_session est vide, oui ==> Là je met à jour cet last_id_session avec l'id session de user1 et il peux se connecter
User2 arrive et veux se connecter avec lulu/12345
Le systeme check si last_id_session de ce compte est vide ==> NON
Le Systeme check l'existence du fichier sess_[last_id_session]:
Il Existe pas ===> le laisse se connecter user2 et je met a jour last_id_session
Il existe ==> je check que la date de la dernière modification du fichier sess_[last_id_session] est > 1 heure:
OUI ==> je le supprime, je met à jour last_id_session en DB avec la session de user2 et le laisse se connecter
NON ===> user2 n'a pas droit de se connecter

Sincèrement, on peut pas faire plus simple!!!

Faut juste que j'arrive à tester l'existence du fichier session (je peux pas tester là mais ça ne serai tarder)

[RunCodePhp]

L'user1 se connect avec son user/mdp (on va dire lulu/12345)
Je check si last_id_session est vide, oui ==> Là je met à jour cet last_id_session avec l'id session de user1 et il peux se connecter
User2 arrive et veux se connecter avec lulu/12345

Non justement, la session ne sera pas 12345, elle sera obligatoirement défférente.

Quand le 1er user arrive, Php lui accorde un ID de session.
Quand le 2ème user arrive, Php lui accordera un autre ID session.
Php n'accordera jamais 2 fois le même ID.


( J'ai plus le temps ... c'est le jour du seigneur parait-il )

[Invité]

Bon, je n'ais pas l'intention de me battre face a vos compétences, je vois bien benthebest que tu touches a du dédié et que tu en connais apparament autant voir plus que moi juste je n'ais fait que défendre mon idée,

1) la sécuritée sur les sessions est trés grande, dés que nous mettons le répertoire de session ors de portée d'un hackeur ! car je l'afirme, seul le serveur peut alors l'atteindre (bien sur les php du site également )

2) Empécher que durand ne se connecte deux fois au même moment,
c' est mission impossible. si vous le réalisez dites moi pr MP votre URL
je prouverais que ça ne va pas.

En effet vous étes OK que je peux de chez moi, arriver avec deux IP (de deux micros différents ) l'un en wifi l'autre du réseau d'entreprise.
vous ne savez pas a un quart d'heure pret ! (c'est pas rien) le quel des "toto_machin" est arrivé en premier ou déconnecté. car je peux travailler sur l'un, et faire une recherche FAQ sur l'autre ...

Cette situation me paraissée ingérable, mais c'est tout, je n'insisterait pas ,juste j'ais consacré du temps , pensant apporter un point de vue qui se défendais, mais bon..

[benthebest]

Non justement, la session ne sera pas 12345, elle sera obligatoirement défférente.

Quand le 1er user arrive, Php lui accorde un ID de session.
Quand le 2ème user arrive, Php lui accordera un autre ID session.
Php n'accordera jamais 2 fois le même ID.


( J'ai plus le temps ... c'est le jour du seigneur parait-il )

Je sais ça! c'est bien pour ça qu'il peut tenter de se connecter, si il avait le même id_session, il serai déjà connecté puisque ce serai lui même!

En gros, le dernier last_id_session qui se trouve en DB est le dernier user à être entré sur le compte lulu/12345, (sauf si ce champs est vide, ça signifie que le dernier user s'est déconnecter proprement en cliquant sur 'Déconnecter" qui, je le rappel, dans mon cas: vide le tableau $_SESSION , vire le cookie de SESSION sur le serveur (setcookie(session.name, temp -42000)), fait un session_destroy() ET MAJ la DB en supprimant le 'last_id_session' (= ''))

[benthebest]

Bon, je n'ais pas l'intention de me battre face a vos compétences

Mais non!! Il s'agit juste d'un débat où chacun défend son point de vue, aucune bagarre n'est déclarée (en tout cas me concernant!!)

2) Empécher que durand ne se connecte deux fois au même moment,
c' est mission impossible. si vous le réalisez dites moi pr MP votre URL
je prouverais que ça ne va pas.

Pas de soucis (essaye déja de faire ça sur ton compte facebook: ouvre une session sous firefox, puis ouvre à coté une session sur IE, puis revient sur firefox et observe )

juste j'ais consacré du temps , pensant apporter un point de vue qui se défendais, mais bon..

Et tu as TRÈS bien fait, car c'est comme ça qu'on arrive à faire le tour de la question et que les futures personnes qui verront se post apprécieront le fait qu'ils n'aient pas à en refaire autant !!

[Invité]

Merci de ta réponse, tu me rassures, sans doute j'avais mal interprétée les réponses.
Revenons a facebook , je vais regarder, mais tu sais que les cookies de session sont unique par nom de domaine/micro par contre les cookies de données sont unique par domaine/navigateur , c'est la ou ils contôlent je penses. Je regardes ça avant ce soir, car là, coté marmaille ça appel a table

[benthebest]

Bon appétit

[Invité]

J'y tenais plus , alors j'ais testé !
la ou je te parles sur un autre onglet de ce micros je viens de télécharger mon avatard facebook, alors que je regardes sur un autre micro mes messages ! cookies de session par micro, j'en était presque certaine !
A bientôt
(Bien sur je refais F5 sur les deux pour contrôler)

[benthebest]

J'y tenais plus , alors j'ais testé !
la ou je te parles sur un autre onglet de ce micros je viens de télécharger mon avatard facebook, alors que je regardes sur un autre micro mes messages ! cookies de session par micro, j'en était presque certaine !
A bientôt
(Bien sur je refais F5 sur les deux pour contrôler)

Tu veux dire que tu as réussit a te connecter et à surfer sur fb en même avec le même compte et avec 2 navigateur différent ? Ca me parait bizzard, en tout cas je n'y arrive pas de chez moi...

[alain31tl]

Slt

Oui mais Maurisier a utilisé 2 machines différentes, ce qui n'est peut-être pas ton cas.

[benthebest]

Ok c'est possible de toute façon je dis pas l'inverse...

Mais le principe reste le même!

[RunCodePhp]

J'y tenais plus , alors j'ais testé !
la ou je te parles sur un autre onglet de ce micros je viens de télécharger mon avatard facebook, alors que je regardes sur un autre micro mes messages ! cookies de session par micro, j'en était presque certaine !
A bientôt
(Bien sur je refais F5 sur les deux pour contrôler)

C'est justement ça qu'il veut éviter : Ne pas pouvoir répondre à un topic sur 2 sessions différente mais un même compte.
C'est l'objet de la question.
FaceBook ou ce forum n'ont tout simplement rien fait dans ce sens, il y a rien d'étrange, c'est totalement normal.

En gros, le dernier last_id_session qui se trouve en DB est le dernier user à être entré sur le compte lulu/12345, (sauf si ce champs est vide, ça signifie que le dernier user s'est déconnecter proprement en cliquant sur 'Déconnecter" qui, je le rappel, dans mon cas: vide le tableau $_SESSION , vire le cookie de SESSION sur le serveur (setcookie(session.name, temp -42000)), fait un session_destroy() ET MAJ la DB en supprimant le 'last_id_session' (= ''))

En faisant comme tu le décris,tu ne profite absolument pas du mécanisme déjà existant des gestions des sessions, du coup, tu y fait la même chose.
Ca fait doublon.
Pourquoi refaire un truc qui existe déjà, et de plus géré par le système, et donc plus rapide et surtout fiable ?


Si tu réfléchi d'ailleurs, tu pourrais même éviter d'enregistrer la session, mais uniquement stocker la date d'expiration.
Dans tous les cas, on s'en fiche pas mal de l'ID de session, il faut juste un élément qui dit que la personne s'est identifiée, et quand sa session doit expirée.
-> Si elle est expirée : On peu continuer, la déclarée identifiée.
-> Si elle n'est pas expirée : Alors elle existe, on refuse un doublon.


Cependant, en te basant sur les fichiers des sessions, tu profite à 100% de la gestion des sessions.
Les fichiers, leur nom c'est l'ID de session. Et si on rajoute dans la session (contenu du fichier) l'ID du user, le problème est réglée.


Petite parenthèse au passage, au niveau de la doc Php, c'est de cette manière que cela ce fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
 
function open($save_path, $session_name)
{
  global $sess_save_path;
 
  $sess_save_path = $save_path;
  return(true);
}
 
function close()
{
  return(true);
}
 
function read($id)
{
  global $sess_save_path;
 
  $sess_file = "$sess_save_path/sess_$id";
  return (string) @file_get_contents($sess_file);
}
 
function write($id, $sess_data)
{
  global $sess_save_path;
 
  $sess_file = "$sess_save_path/sess_$id";
  if ($fp = @fopen($sess_file, "w")) {
    $return = fwrite($fp, $sess_data);
    fclose($fp);
    return $return;
  } else {
    return(false);
  }
 
}
 
function destroy($id)
{
  global $sess_save_path;
 
  $sess_file = "$sess_save_path/sess_$id";
  return(@unlink($sess_file));
}
 
function gc($maxlifetime)
{
  global $sess_save_path;
 
  foreach (glob("$sess_save_path/sess_*") as $filename) {
    if (filemtime($filename) + $maxlifetime < time()) {
      @unlink($filename);
    }
  }
  return true;
}
 
session_set_save_handler("open", "close", "read", "write", "destroy", "gc");
 
session_start();
 
// Utilisez vos sessions comme d'habitude

Mais tu fais comme tu le sens.
Théoriquement, ça devrait fonctionner.

Tu veux dire que tu as réussit a te connecter et à surfer sur fb en même avec le même compte et avec 2 navigateur différent ? Ca me parait bizzard, en tout cas je n'y arrive pas de chez moi...

Pourquoi n'y arriverait tu pas ? Il y a aucune raison.

[Invité]

Pourquoi n'y arriverait tu pas ? Il y a aucune raison.

Si parce que lui le fait avec deux navigateurs sur un seul micro, alors pour moi c'est clair

un seul cookies de session par domaine/micro
un seul cookies de données par domaine/navigateur

Donc lui il y a conflit entre l'ID de session de ces deux navigateurs,
par rapport au contenu des Cookies de données.

Alors que moi sur les deux micros , j'ais bien la même IP, puisque une seule livebox mais par contre
Deux ID de sessions (une par micro) cohérentes avec leurs cookies de données ....

Je sents que ça se précise non ?

[RunCodePhp]

un seul cookies de session par domaine/micro
un seul cookies de données par domaine/navigateur

Je sents que ça se précise non ?

Suffit de faire des essais avec 2 navigateurs différents, comme tu l'as précisé.


Par contre, il y aura un truc qu'il sera plus difficile à 'éviter, c'est d'avoir 2 onglets du même compte, ou 2 pages du même compte sur un même post.
Ceci dit, on parle toujours de 2 personnes (physiquement) différentes.
Ca donnera lieu à 2 sessions différentes.

[benthebest]

Si tu réfléchi d'ailleurs, tu pourrais même éviter d'enregistrer la session, mais uniquement stocker la date d'expiration.
Dans tous les cas, on s'en fiche pas mal de l'ID de session, il faut juste un élément qui dit que la personne s'est identifiée, et quand sa session doit expirée.
-> Si elle est expirée : On peu continuer, la déclarée identifiée.
-> Si elle n'est pas expirée : Alors elle existe, on refuse un doublon.


Cependant, en te basant sur les fichiers des sessions, tu profite à 100% de la gestion des sessions.
Les fichiers, leur nom c'est l'ID de session. Et si on rajoute dans la session (contenu du fichier) l'ID du user, le problème est réglée.

Donc si j'ai bien compris ta méthode, il faut boucler sur tous les fichiers de sessions et checker dans chacun si il y a déjà l'id user de celui qui tente de se connecter?

Si oui ==> connexion interdite, c'est bien ça??

Mais le problème de cela c'est que malheureusement il peux rester un fichier session obsolète (comme je l'ai dit au début, j'ai retrouvé un fichier session qui datait de 2 jours car le GC n'avait pas était activé...) et qui peut contenir l'id_user...

Tu vas me dire "oui mais comme tu l'a dis ce fichier est obsolète", je te répond oui mais donc dans tous les cas on doit checker la date de dernière modification, mais à la différence que moi je ne check pas tous les fichiers session (mais seulement l'existence d'un fichier précis)

Non? Dis moi ce que tu en penses ou si je me trompe...

[RunCodePhp]

Tu vas me dire "oui mais comme tu l'a dis ce fichier est obsolète", je te répond oui mais donc dans tous les cas on doit checker la date de dernière modification, mais à la différence que moi je ne check pas tous les fichiers session (mais seulement l'existence d'un fichier précis)

Disons que tu fais comme tu veux.

Si tu préfère enregistrer cette info dans ta Bdd, (table user), pourquoi pas.
Mais là, à mon avis, la seule info qui serait utile serait d'y rajouter la date d'expiration : date en court + 10 minutes, au moment où la personne sera considérée comme logguée.
Du coup, il y n'a pas utilité ici de contrôler les fichiers de sessions.

Le seul truc, c'est que cette info est propre au sessions, c'est un peu pour ça qu'il me semble plus logique de faire la vérif au niveau des sessions.


Maintenant, encore une fois, c'est à toi de voir.
L'une ou l'autre devrait fonctionner, et tout repose sur la date d'expiration et l'ID du user (très peu, voir pas du tout sur l'ID de session).



Je me demande si je ne rajouterais pas cette fonctionnalité dans mon truc, car si on regarde bien, c'est assez simple finalement, ce n'est pas lourd, et ça fait une tentative de hack/piratage de moins.
Je vais essayé, ça ne devrait pas me prendre des plombes, je te tiens au courant.

[benthebest]

Mais là, à mon avis, la seule info qui serait utile serait d'y rajouter la date d'expiration : date en court + 10 minutes, au moment où la personne sera considérée comme logguée.
...

L'une ou l'autre devrait fonctionner, et tout repose sur la date d'expiration et l'ID du user (très peu, voir pas du tout sur l'ID de session).

Y a un truc que j'ai pas pigé quand même (c'est le problème des forums on a du mal à se faire comprendre des fois )...

Je suis d'accord quand tu dis que tout repose sur l'id user mais pourquoi la date d'expiration aussi?

On ne sait pas vraiment quand la session expire précisément puisque dans mon cas (j'ai du vous le préciser) la session de l'user n'expire soit quand il se déconnecte à la main, soit lorsqu'il ferme son navigateur...

En plus de cela, si je conserve le time du log, en prenant ce temps + 10 minutes (par exemple), user1 peut être malgré tout actif dans sa session et ne peut être déconnecter pour autant... ==> ce temps n'a pas de pertinence?!

On s'est mal compris ou il y a quelque chose qui m'échappe

[Invité]

Ca y est, je vais encore me faire huer, mais force est de dire que dans aucune méthode informatique ou autre,
on ne peut valablement mélanger deux méthode.mpanuelle et automatique.

Ou vous vous faites vos session a la main et là c'est de la base de donnée Mysql.
Ou vous laissez faire le systéme .

Je vais sur ton site, je me connecte, un enfant m'appelles et je reviens 1/4 d'heure aprés, je change de page et tu me demandes de me loguer ...
ça c'est la perte des données cause fichier du serveur timeout !
ça réponds a ton intérogation, l'ID "jjhdkjhjkh!!55qs54dqqs54qds" est bien dans mon cookies de session, ET LE SERVEUR A BIEN
jjhdkjhjkh!!55qs54dqqs54qds.txt mais sa date est dépassée