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.