Discussion :

[aze555666]

Bonjour,

Je suis en cours de développement d'un site qui permettra aux utilisateurs d'entrer pas mal de texte, et même (de façon très limitée) des images.
Ce site est hébergé sur un serveur dédié, et de ce fait je suis obligé de log toutes les entrées $_POST et $_GET avec les IP des gens (ou tout au moins c'est ce que j'en ai compris, cf. texte en bas de ce post)


Je pense faire un script dédié qui fera une boucle sur $_POST et $_GET.

Restent deux solutions techniques
a) utilisation d'un fichier de log standard
b) insertion dans une table de log en BDD

Je cherche avant tout à éviter que cette histoire de log ne surcharge mon serveur. Sachant que j'aurais de toute façon déjà une connexion mysqli ouverte, est-ce que faire des insert avec un prepared statement qui serait exécuté pour chaque valeur post/get mangerait beaucoup plus de ressources serveur qu'ajouter des lignes à la fin d'un fichier de log ?

Merci,

Cordialement,

aze555666


ps : pour info, extrait des conditions de location d'un serveur dédié OVH

Le Client doit dès lors être considéré comme un hébergeur au sens de l'article 6.I.2 de la loi pour la Confiance dans l'Economie Numérique du 21 juin 2004, puisqu'il assure, pour mise à disposition du public par des services de communication au public en ligne, le stockage de signaux, d'écrits, d'images, de sons ou de messages de toute nature fournis par les destinataires de ces services. Il lui appartient dès lors de détenir et conserver, en application de l'article 6.II de la loi précitée, l'ensemble des données de nature à permettre l'identification de quiconque a contribué à la création du contenu ou de l'un des contenus des services dont il est prestataire et ce pour une durée de 12 mois, sans que la responsabilité d'OVH puisse être à cet égard engagée. Il appartient également au Client, en application de l'article 6.I.7 de la loi pour la Confiance dans l'Economie Numérique du 21 juin 2004, de mettre en place un dispositif facilement accessible et visible permettant à toute personne de porter à sa connaissance toute infraction constitutive d'apologie de crime contre l'humanité, d'incitation à la haine raciale, de pornographie enfantine, d'incitation à la violence, ainsi que d'atteinte à la dignité humaine, ou encore d'activités illégales de jeux d'argent.

[rawsrc]

Salut,

D'entrée de jeu je te dirai de rester sur la BDD. Par ailleurs, je te déconseille de faire une insertion pour chaque valeur d'une soumission dans le log. Tu gagneras du temps et des ressources en ne sauvegardant que la version serialisée de ce que tu as à sauvegarder.

Enfin avant de te lancer là-dedans, je te rappelle une chose c'est que tu dois être juste capable d'assurer l'identification de l'auteur d'une publication (dans la mesure du possible). Donc s'il y a publication, tu n'as plus qu'à lui coller les données d'identification de l'auteur et tu as ton log de par l'usage de ton site... Pas besoin d'aller plus loin.

[aze555666]

Merci pour ta réponse.

En ce qui concerne l'identification de l'auteur d'un contenu, ça implique à priori de la log même si mes contenus sont associés à un UserID. En effet, je ne stock pas l'IP des gens dans ma table des users.
Je pourrais me contenter de faire une table listant les IP au login, mais je me dis que faire un vrai log sera de toute façon utile pour l'administration de mon site.

[rawsrc]

Tu dois créer une table t_connexion et garder toutes les infos de la connexion et en plus l'horodatage.
Ensuite pour tes publications : tu ne dois rien faire de plus que de suivre le user_id (comme tu le fais déjà) et ne rajouter que l'horodatage à la publication. En croisant les horodatages, tu sauras avec quelle connexion, la publication a été faite...

Après pour ce qui est du "vrai" log, c'est un vaste sujet. Sans compter que le moteur de base de données peut grandement t'aider.

[aze555666]

Je pensais que c'était tout bon mais avec ton dernier message je suis tout perdu ^^

Tu dois créer une table t_connexion et garder toutes les infos de la connexion et en plus l'horodatage.

Est-ce que ceci veut dire que ce que demande la loi m'oblige à stocker plus que l'adresse IP et l'horodatage ? C'est quoi "toutes les infos de connexion"? Je n'en vois pas trop d'autre qui soit "de nature à permettre l'identification ...".

Sans compter que le moteur de base de données peut grandement t'aider.

Je n'ai pas connaissance que mysql conserve d'historique des modifications effectuées sur la base (update, insert, delete) ?

edit : sur le dernier point si il s'agit de mettre des trigger partout, ça ne me dira pas par où sont arrivées les données, donc je préfère un insert depuis php.

[rawsrc]

Salut,

Les autres infos de connexion ce sont les infos renvoyées par le client que tu peux récupérer avec $_SERVER au moment de la connexion. Tu peux très bien faire une photo de ces infos et les conserver.
Quand tu cherches à identifier un client, il ne suffit pas de regarder juste son IP. C'est plus complexe que ça. Sans compter que l'IP peut très bien être modifiée durant une même session...
Tous ces aspects concernent la sécurité en général que tu te dois d'assurer à des fins de fiabilité de ton processus d'identification.

Dès que tu offres la possibilité à des tiers de contribuer au contenu de ton site, tes obligations légales augmentent drastiquement.

Pour l'aspect technique, c'est pareil : c'est beaucoup plus contraignant : tu dois essayer de prévenir les attaques courantes liées au fait que tu ouvres une porte d'accès à ton contenu.

Après pour ce qui est des logs des SGBDR, il faut mettre les mains dans le cambouis mais je peux te garantir que tous les SGBDR offrent des possibilités très poussées en matière de log. J'ai même vu des bases de données entièrement/partiellement reconsitutuées rien qu'en parsant les logs. Et sans aucun trigger.
Regardes du côté des logs binaires de MySQL et/ou du log général des requêtes.

[aze555666]

Pour ce qui est des infos légales, et en l'absence d'une liste précise, je vais faire mon bourrin.
- id d'entrée de log auto increment
- id utilisateur = $_SESSION['UserID']
- timestamp = now()
- page = $_SERVER['PHP_SELF']
- server = print_r($_SERVER, true)
- session = print_r($_SESSION, true)
- post = print_r($_POST, true)
- get = print_r($_GET, true)

Avec un insert fait dans un script appelé par chaque php qui fait des insert/update.
C'est bourrin mais ça reste une seule action d'insert, ça ne devrait donc pas changer de beaucoup les perfs. Perfs dont ma motivation pour les optimiser vient de sérieusement prendre un coup suite à la lecture d'un article de SQLpro qu'il m'a envoyé lire dans un autre topic (http://www.developpez.net/forums/d12...te-meme-table/)



Pour ce qui est des attaques courantes, je ne suis pas un expert en sécurité mais je devrais être protégé. Je connais les suivantes
- injection sql: prepared statements -> ok
- injection cookie: login uniquement par session, pas de cookie -> ok
- xss: les upload d'images sont vérifiés, et je met des htmlspecialchars() partout.



Par contre je me pose une question. D'après ce que tu me dis, cette loi nous oblige à faire un tas de truc: log d'un certain nombre d'infos sur l'utilisateur qui ne se limitent pas à l'IP, sécurisation ...
J'avais cherché des tutoriels expliquant clairement ce que je dois faire pour la respecter mais ... rien. C'est moi qui utilise les mauvais mots clés ou personne n'en a écrit en 8 ans ? Oo

[ascito]

Alors moi voila comme je procèdes

une table user (idUser , infos user lors de l'inscription ) , si l'email na pas été validé il ne peu pas se servir des Modules d’Edition

une table
contenu ( idUser , detail du contenu, date timeStamp , etc )

une table log
idUser , 'connexion' ,tiMestamps , detail client par $_SERVER + creation d'un token unique)
idUser , 'envoi_message' , timestamp , details supplémentaire au message +token

Donc je logs toutes les actions dites "critiques", en même temps que le reste des autres traitement ( tout en vérifiant que le token est présent )

l'user peux se déconnecter avec un bouton, ou lors de la fermeture du navigateur, une session expire au bout de 3 heures

tu peux donc vider ta table log au bout de timestamp + un ans chez ovh, et toi si tu as un problème tu vois ça en temps réel