Discussion :

[Baptiste Wicht]

Bonjour

Je suis en train de developper un petit forum pour mon site web et j'en suis à la partie connexion et je bloque un peu sur quelques petites choses.

Je sais comment employer un Cookie et une Session, c'est plutôt des problèmes d'ordre stratégique que technique.

Alors voici sans attendre les quelques interrogations que je me pose :

1. Pour ce qui est de la connection, je sais que c'est faisable avec des cookies et avec des sessions, mais c'est quoi le mieux ?
2. Ensuite, je me demandais aussi ce qu'il en était des messages lus/non lus... Je vois plusieurs solutions : Tout simplement, avoir une table lectures dans la base de données, dans laquelle je fais des associations ID du membre et ID de la discussion (C'est pratique car je suis sûr qu'un message lu est lu et qu'un non lu ne l'est pas, mais c'est vite lourd) ou alors, je me base sur le timestamp de la dernière visite et j'efface tout ce qu'il y a avant (là, c'est plus léger, mais c'est pas spécialement pratique pour l'utilisateur)
3. Troisièmement, j'aimerais savoir les personnes qui sont connectées actuellement, mais je vois pas trop comment faire. Pour dire qu'une personne est connecté, très simple, je met un champ logged = 1 et il est connecté, mais c'est la deconnexion qui pose problème. Si par exemple il ferme son navigateur, comment je peut dire qu'il n'est plus là...
4. Ensuite, pour ce qui est des droits qu'ont les utilisateurs, le mieux c'est de les stocker (session ou cookie) ou alors de les extirper de la base de données sur chaque page ?
5. Sinon, avez vous des conseils à me donner pour la création de mon forum ?
6. Et encore une dernière, avez-vous des liens sur la création d'un forum et surtout sur la gestion des connections, droits et message lus/non lus ?
7. Sans oublier, un énorme à ceux qui auront la gentilesse de prendre du temps pour répondre à ces questions

[Eusebius]

Pour ce qui est de la connection, je sais que c'est faisable avec des cookies et avec des sessions, mais c'est quoi le mieux ?

Je te conseillerais de toujours te reposer sur les sessions, qui sont plus sécurisées (mais qui peuvent faire appel aux cookies, suivant ta configuration). Libre à toi ensuite d'utiliser un cookie pour se souvenir du visiteur, comme sur DVP.

Troisièmement, j'aimerais savoir les personnes qui sont connectées actuellement, mais je vois pas trop comment faire. Pour dire qu'une personne est connecté, très simple, je met un champ logged = 1 et il est connecté, mais c'est la deconnexion qui pose problème. Si par exemple il ferme son navigateur, comment je peut dire qu'il n'est plus là...

Je pense que tu peux faire des tas de choses avec cette fonction :
http://fr.php.net/manual/fr/function...ve-handler.php
Mais par contre je suis pas sûr que ça soit très facile !
Sinon je me souvenais d'un moyen de spécifier une fonction de type callback pour quand la session est détruite, mais me souviens plus c'est ptet ma mémoire qui me joue des tours aussi.

Ensuite, pour ce qui est des droits qu'ont les utilisateurs, le mieux c'est de les stocker (session ou cookie) ou alors de les extirper de la base de données sur chaque page ?

Dans les "bonnes pratiques", on suggère de ne conserver que les identifiants qui permettent de regénérer les permissions, c'est moins sensible aux attaques.

Voilà... J'ai pas de réponse "magique" à tes questions, désolé ! Bon courage !

[Yogui]

Salut

1. Les cookies servent pour se souvenir de l'utilisateur entre chaque session et éventuellement pendant la session (dépend de la méthode de propagation du SID : par URL ou par cookie). Les sessions te servent à ne pas mettre trop de choses dans les cookies, car ce sont des informations facilement modifiables par l'utilisateur (donc falsifiables). Tu peux gérer les informations de session avec la BDD : c'est un peu plus lourd mais + sécurisé.
2. Enregistre l'id_user et l'id_post dans une table. Cela te permet de savoir s'il y a eu de nouveaux messages depuis la dernière lecture. C'est un peu lourd mais il faut ce qu'il faut... Pense à faire le ménage à chaque fois que tu insères un tuple.
3. Il est préférable de mettre les sessions dans la BDD pour des raisons de sécurité et pour permettre certaines choses. Les stats globales en font partie. Enregistre la date dernière activité de l'utilisateur dans sa table : cela te permet à la fois de gérer la date d'expiration du cookie et les stats sur les users connectés.
4. cf. le premier point : met tout en base de données.
5. Question trop vaste... Vas-y tranquillement, commence par l'analyse (Merise, UML, etc.) et ne saute pas d'étape.

[Eusebius]

Tu peux gérer les informations de session avec la BDD : c'est un peu plus lourd mais + sécurisé.

Comment on gère les sessions par la DB, vite fait ? (juste les principes)

[Yogui]

Au lieu de faire :

Code :

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

$_SESSION['variable'] = 'truc';

Tu fais une requête INSERT INTO ou UPDATE.

Tu vois l'idée ?

[Eusebius]

Au lieu de faire :

Code :

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

$_SESSION['variable'] = 'truc';

Tu fais une requête INSERT INTO ou UPDATE.

Tu vois l'idée ?

oué ok, j'avais l'impression que tu disais qu'il y avait quelque chose de standard, à la manière du session.use_cookies, mais je crois que j'ai forcé sur l'apéro
Mais la question de wichtounet reste valable, comment est-ce qu'on sait, de manière simple, quand la session est terminée ?

[Yogui]

N'enregistre pas "logged" dans la table User mais plutôt (comme je l'ai proposé plus haut) la date (timestamp Unix) de la dernière activité de l'utilisateur.
Quand tu charges une page, regarde quand a eu lieu la dernière activité de cet utilisateur. Soustrais 5 minutes (en admettant que le timeout soit de 5 minutes) pour savoir s'il est en ligne. Cela permet à la fois de savoir qui était en ligne dans les 5 dernières minutes et de déterminer à partir de quand l'utilisateur n'est plus connecté.

Bien sûr, tu peux mettre un évènement JavaScript sur la fermeture de la fenêtre mais chacun sait que JavaScript n'est pas assez fiable (peut être désactivé ou manipulé), il faut donc mettre en place un sysème de timeout.

Nous sommes également en train de préparer un tutoriel sur la sécurité en PHP. Il se fait un peu attendre car c'est un très gros morceau, mais tout cela sera traité.

[Baptiste Wicht]

beaucoup à vous deux, c'est exactement ce qu'il me fallait

Donc, en fait, ma sessions sert juste à me dire s'il est connecté ou pas et qui est connecté ? Et je stocke toutes les infos dans la db.

Juste une phrase que j'ai pas comprise :

Pense à faire le ménage à chaque fois que tu insères un tuple.

Et aussi un petit truc, quand il clique sur se deconnecter, je fais quoi pour dire qu'il est déconnecté tout de suite, je diminue son timestamp ?

[Yogui]

En ce cas, le bouton "déconnecter" ne sert pas nécessairement à changer quoi que ce soit en BDD mais surtout à supprimer les cookies.
Si tu utilises la base de données, alors la session ne te sert guère qu'à propager l'ID de session. Les cookies devraient te permettre de savoir si ton utilisateur est connecté ou non.

Pour le ménage, voici la problématique :
lorsqu'un utilisateur visite un sujet du forum, tu enregistres dans la BDD le user_id et le post_id. Cela te permet de retrouver aisément les sujets non lus et à partir de quel message ils sont nouveaux. Le souci est que cette méthode te permet d'insérer plusieurs tuples pour le même sujet. Il faut donc supprimer tous les tuples correspondant à ce user_id et ayant un post_id appartenant au même topic_id que le topic_id du dernier message affiché. Je ne sais pas si je suis bien clair...

Prenons l'exemple de ce sujet-ci : le sujet numéro 181802 contenant les messages numéros 1166039, 1166144 et 1166234. L'utilisateur numéro 30724 (Yogui) vient de poster le dernier des trois messages, il a donc tout lu et tu insères 1166234 et 30724 dans la base de données.
Ensuite, le message 1166275 est enregistré par un autre utilisateur (Eusebius), ce qui fait que le sujet passe à non lu pour Yogui à partir de ce message. Notre Yogui revient visiter le sujet, ce qui nous fait entrer les valeurs 1166275 et 30724 dans la base de données.
Souci : 1166275 (le nouvel id) et 1166234 (l'ancien déjà en BDD) appartiennent au même sujet numéro 181802, ce qui fait que l'ancien tuple est devenu obsolète.
Conclusion : à chaque fois que tu enregistres un tuple dans cette table, commence par supprimer tous les tuples ayant ce user_id (ici : 30724) et un post_id appartenant à ce topic_id (ici : 181802). N.B. : Il ne devrait toujours y en avoir qu'un (voire aucun) à supprimer.

[Amine_sas]

1- Je pense que les sessions sont plus pratiques car certains navigateurs n'acceptent pas les cookies.

2- La premiere solution est meilleure et plus commode pour l'utilisateur que la 2eme.

3- Tu ajoute un lien de deconnexion. Pour ceux qui ferment le navigateur sans cliquer sur le lien, tu peux jouer sur le delai d'expiration d'une session (si un utilisateur n'effectue aucun changement pendant une certaine periode te temps predefinie, il sera considerè deconnecté).

4- A mon avis c'est de les stocker dans la BDD.

5- La creation d'un moteur de recherche multicriteres (theme, mots clés, date...) pour le forum, c'est sympa.

[Baptiste Wicht]

En ce cas, le bouton "déconnecter" ne sert pas nécessairement à changer quoi que ce soit en BDD mais surtout à supprimer les cookies.
Si tu utilises la base de données, alors la session ne te sert guère qu'à propager l'ID de session. Les cookies devraient te permettre de savoir si ton utilisateur est connecté ou non.

Là, je suis pas encore sûr d'avoir tout compris...

Je fais comment le lien entre l'id de session et l'utilisateur lui-même ? Faut bien que je stocke ça, non ?

Pour le ménage, voici la problématique :
lorsqu'un utilisateur visite un sujet du forum, tu enregistres dans la BDD le user_id et le post_id. Cela te permet de retrouver aisément les sujets non lus et à partir de quel message ils sont nouveaux. Le souci est que cette méthode te permet d'insérer plusieurs tuples pour le même sujet. Il faut donc supprimer tous les tuples correspondant à ce user_id et ayant un post_id appartenant au même topic_id que le topic_id du dernier message affiché. Je ne sais pas si je suis bien clair...

Prenons l'exemple de ce sujet-ci : le sujet numéro 181802 contenant les messages numéros 1166039, 1166144 et 1166234. L'utilisateur numéro 30724 (Yogui) vient de poster le dernier des trois messages, il a donc tout lu et tu insères 1166234 et 30724 dans la base de données.
Ensuite, le message 1166275 est enregistré par un autre utilisateur (Eusebius), ce qui fait que le sujet passe à non lu pour Yogui à partir de ce message. Notre Yogui revient visiter le sujet, ce qui nous fait entrer les valeurs 1166275 et 30724 dans la base de données.
Souci : 1166275 (le nouvel id) et 1166234 (l'ancien déjà en BDD) appartiennent au même sujet numéro 181802, ce qui fait que l'ancien tuple est devenu obsolète.
Conclusion : à chaque fois que tu enregistres un tuple dans cette table, commence par supprimer tous les tuples ayant ce user_id (ici : 30724) et un post_id appartenant à ce topic_id (ici : 181802). N.B. : Il ne devrait toujours y en avoir qu'un (voire aucun) à supprimer.

C'est bon, j'ai bien compris,

J'espère que ma base de données va supporter ça, mais comme j'aurai pas une tonne d'utilisateurs au début, ca devrait aller.

[Eusebius]

Je fais comment le lien entre l'id de session et l'utilisateur lui-même ? Faut bien que je stocke ça, non ?

L'utilisateur s'est sans doute loggé avec un login et un password, tu peux travailler là-dessus + récupérer l'id de session avec session_id()

[Baptiste Wicht]

L'utilisateur s'est sans doute loggé avec un login et un password, tu peux travailler là-dessus + récupérer l'id de session avec session_id()

Je sais qu'il s'est connecté avec un mot de passe et un user et je sais aussi que je peut avoir l'id de session, mais je fais quoi pour les lier ?

La meilleure solution que je vois, en ne stockant rien dans la session, est de mettre un champ SessionId dans la BDD et en y stockant aussi l'ip pour être sûr.

[Eusebius]

Je sais qu'il s'est connecté avec un mot de passe et un user et je sais aussi que je peut avoir l'id de session, mais je fais quoi pour les lier ?

La meilleure solution que je vois, en ne stockant rien dans la session, est de mettre un champ SessionId dans la BDD et en y stockant aussi l'ip pour être sûr.

Ben pour faire le lien, tu peux faire comme ça effectivement, une table ou tu associes les PHPSESSID, les IP et les logins...

[Yogui]

Exactement

[Baptiste Wicht]

Exactement

Génial

à tous

[Invité]

Tu peux gérer les informations de session avec la BDD : c'est un peu plus lourd mais + sécurisé.

Hello,

Je lis la même chose depuis longtemps : Gérer les sessions avec la BDD est plus sécurisé, hors, en dehors du fait que le stokage dans une table puisse effectivement élargir les fonctionnalités...Je ne vois pas en quoi cela est plus sécurisé... (enfaite, ce n'est que déplacer le problème, si pas l'empirer, selon moi).

J'ai l'impression que c'est encore une de ces bonnes pratiques démago dont personne ne connait l'origine, mais qu'on répend volontier, un peu comme l'histoire de la méchante super-globale $_REQUEST et la directive variable_order ! .

Je peux conçevoir le vol de session (par SID ou vol de cookie...), la manipulation des cookies coté client, ou des injections à partir de register_global à on, des attaques CSS ou même des headers HTTP spécialement forgés.

Parcontre je comprends toujours pas en quoi la sécurité d'un fichier temporaire (La session, coté serveur) et plus fragile qu'un stockage en base de données...

Si vous avez des explications concrètes, je suis hautement preneur !

[Yogui]

Pourquoi la variable $_REQUEST est-elle mauvaise ?
Parce que tu ne sais pas exactement d'où proviennent ses informations : $_GET, $_POST, $_COOKIE, etc. Il se peut que tu souhaites récupérer une information de cookie mais qu'en fait ton petit malin d'internaute te l'ait envoyée en GET pour essayer de te pirater.

Pourquoi faut-il faire attention à variable_order ?
Si register_globals est activé ou si l'on utilise $_REQUEST, je viens d'en donner la raison.

Pourquoi les sessions sont-elles vulnérables ?
Il faut savoir que les sessions sont enregistrées sur le disque du serveur. À ce titre, PHP peut naturellement accéder directement au fichier de stockage des sessions. C'est dangereux dans le cas d'un hébergement mutualisé : dans certains cas, il est tout à fait possible qu'un utilisateur de l'hébergement utilise un chemin d'accès absolu pour lire le fichier de stockage des sessions d'un autre client du même hébergeur.
Bien sûr, le risque est réduit. Il faut que votre pirate soit hébergé sur le même serveur physique que vous... Cependant, c'est un risque.
En revanche, la base de données offre un niveau de sécurité supplémentaire puisqu'il faut utiliser un login et un mot de passe pour pouvoir accéder aux informations. Cela dit, votre client voisin peut probablement lire votre fichier de configuration contenant ces informations sensibles...
Tout dépend de la manière dont est configuré le serveur.

[Invité]

Pourquoi la variable $_REQUEST est-elle mauvaise ?
Parce que tu ne sais pas exactement d'où proviennent ses informations : $_GET, $_POST, $_COOKIE, etc. Il se peut que tu souhaites récupérer une information de cookie mais qu'en fait ton petit malin d'internaute te l'ait envoyée en GET pour essayer de te pirater.

Pourquoi faut-il faire attention à variable_order ?
Si register_globals est activé ou si l'on utilise $_REQUEST, je viens d'en donner la raison.

Pourquoi les sessions sont-elles vulnérables ?
Il faut savoir que les sessions sont enregistrées sur le disque du serveur. À ce titre, PHP peut naturellement accéder directement au fichier de stockage des sessions. C'est dangereux dans le cas d'un hébergement mutualisé : dans certains cas, il est tout à fait possible qu'un utilisateur de l'hébergement utilise un chemin d'accès absolu pour lire le fichier de stockage des sessions d'un autre client du même hébergeur.
Bien sûr, le risque est réduit. Il faut que votre pirate soit hébergé sur le même serveur physique que vous... Cependant, c'est un risque.
En revanche, la base de données offre un niveau de sécurité supplémentaire puisqu'il faut utiliser un login et un mot de passe pour pouvoir accéder aux informations. Cela dit, votre client voisin peut probablement lire votre fichier de configuration contenant ces informations sensibles...
Tout dépend de la manière dont est configuré le serveur.

Bonjour,

Merci pour tes réponses.


En ce qui concerne les sessions,
Je m'y attendais un peu !

Ce n'est pas le système de session PHP qui est à remettre en cause, ni même la façon de stocker l'information, le problème se situe à un niveau d'abstraction supérieur : Le contexte d'hébergement et les privilèges utilisateur. Bon, en partant de là, c'est simple : on peut tout remettre en cause... Même l'hebergeur.

Et dans ce cas, la notion d'utilisateur et mot de passe pour une base de données est totalement relative (de mon point de vue), je m'explique :

Dans le cas d'un serveur mutualisé, l'accompte utilisé pour la base de données devrait être le même que celui utilisé pour l'éxécution, la lecture ou l'écriture d'un fichier sur le serveur Web...

Si cet accompte est (par principe) propre à chaque client : les accès "voisins" sont impossibles (à moins que le groupe d'utilisateurs ait un droit d'accès commun sur tous les fichiers, ce qui serait une grossière erreur de l'hebergeur...).

Enfin tout ça relève plus des privilèges utilisateurs au niveau du système que de PHP lui-même...


Concernant $_REQUEST (je veux pas créer de polémique ! )

Connaître la provenance d'une information importe peu dans le cas que tu as cité, si le "petit malin" cherche à compromettre un script, que ce soit par GET, POST, ou COOKIE, cela importe peu, à la limite, il va gagner du temps. Si il est capable d'exploiter une faille par GET à destination d'un variable sensée être COOKIE, le problème ne vient pas des super-globales, mais bel et bien du script qui reçoit les infos... Résultat final : du pareil au même.

Après qu'on me dise qu'il peut y avoir des incohérences avec $_REQUEST à cause de variable_order si des variables GPC portent le même nom : C'est une question de programmation. Si on programme proprement, on nomme ses variables sans ambiguïté et l'existence de $_REQUEST n'est pas controversée.

Bye

[Yogui]

Tout à fait d'accord. Le tout est de savoir ce que l'on fait.

Concernant l'hébergement, je viens de tester avec un 60GP d'OVH : impossible de lire un fichier d'un autre utilisateur du même serveur. La faille décrite par Chris Shiflett n'est donc pas systématiquement exploitable. D'ailleurs, la doc PHP explique bien que PHP hérite des privilèges de l'utilisateur système. Si le serveur est bien configuré, la faille n'a pas lieu d'être.

En sécurité, il est sage de tout remettre en question, tu ne crois pas ?

Bien sûr, le nom d'utilisateur FTP et SGBD peut coïncider avec le nom d'utilisateur système, voire avec celui d'autres daemons. Cependant, les mots de passe doivent tous être uniques. Un mot de passe devrait toujours avoir une utilisation unique.

Bref, c'était une petite digression qui n'a pas sa place ici.