Gestion des fichiers log et retour en arriere - PHP - Programmation
Marsh Posté le 09-09-2005 à 14:54:33
Ce que tu cherches a faire porte un nom : de l'audit trail. (avec ce nom tu devrais trouver plus de truc sur le net)
Ca ne se fait pas en php mais avec une BDD
Tu dois certainement utiliser mysql, et a ma connaissance il n'y pas de fonctions de ce genre ds cette BDD.
Tu dois donc le gérer toi-même mais je ne pense pas que ton post ai une place sur le forum php
Tu peux très bien stocker ttes les requetes qui passe avec un timestamp ds un fichier log ou bien ds un table, mais après tu vas galérer pour retrouver qui a fait quoi
Marsh Posté le 09-09-2005 à 15:01:52
PatraK a écrit : |
faux
le log binaire c'est quoi?
Marsh Posté le 09-09-2005 à 15:12:55
ah oui c'est bien ça en plus c'est compatible avec les transactions!
Je sens que ca devrait répondre a ta question Loizo, pour les retours arrière aussi du coup.
en resumé fouille les fonctions de la BDD
Marsh Posté le 09-09-2005 à 15:27:39
Ok merci pour vos réponses
Je vais me renseigner sur l'audit trail juste pour voir ce que c'est puisque a priori ce n'est pas la meilleure solution et je vais regarder les log binaire dont vous discutiez puisque je n'en est jamais encore entendu parlez.
Merci bcp !
Marsh Posté le 09-09-2005 à 15:48:04
J'suis en train de regarder la et y a des trucs que je ne comprend pas bien fait. A priori les deux méthodes ont l'air pas mal. Je suis en train de lire un article Anglais d'un gars qui a réalisé un Audit Trail avec php et mysql donc c'est cool et j'ai regardé le manuel mysql pour les logs binaires.
Le truc c'est que dans les deux cas on enregistre les requetes, qui l'a faite, quand etc etc mais je ne vois pas comment revenir en arriere. Pour l'audit trail je suis encore en cours de lecture donc ca va ptet venir mais pour les Log Binaire je ne vois pas. Parce que a priori si on vire une fiche sur le site, cette fiche contient des infos (le contenu : photo, description, nom, type...) or je ne vois pas ou sont enregistrées ces infos pour pouvoir recréer la fiche a l'identique. Mais peut etre n'est ce pas possible... En tout cas pour enregistrer les evenements c'est nickel
Marsh Posté le 09-09-2005 à 17:28:57
si tu veux pouvoir revenir en arriére, alros le plus simple, c'est de ne rien suprimer mais d'utiliser une colone booleene indiquanjt si la ligne est suprimé ou non.
Et si tu veux pas avoir une telle colone dans ta tabl,e il te faiut sauvegarder dans une table jumelle tout ce qui sera suprimé.
Sinon, si c'est en php avec une base de donnée, il est possible de logguer toutes les actions soit dans une table prévus pour soit dans un fichier texte.
Marsh Posté le 09-09-2005 à 17:40:45
Le truc c'est que je me demandais si il y avait moyen d'eviter de sauvegarder tout ce qu'on supprime mais bon a priori c'est obligatoire c'est logique. Mais je pense apres reflexion qu'avec les log binaire ca va marcher nickel, surtout si je peux enregistrer des valeurs perso comme la valeur des champs de certains attributs. A voir
Merci
Marsh Posté le 09-09-2005 à 17:48:50
les logs binaires de mysql servent à deux chôses : finir des modifs si le serveur à été coupé au milieu (coupure de courant par exemple) et permettre une mise à niveau d'un autre serveur mysql s'il y a eu coupure de la liaison entre les deux pendant une periode indéterminé.
A ma conaissance, ca ne permet pas d'anuler des supressions. Du moins, ce n'est pas leur but. D'ailleur rien ne dit que le serveur sauvegardera les logs binaire depuis la création de la base de donnée.
Au fait, le log binaire de mysql se contente de contenir les requettes de changement de données (création, supression ou simple modif) sous une forme binaire avec quelques infos en plus. (entre autre quel serveur a reçu cette demande de requette)
Marsh Posté le 09-09-2005 à 19:37:00
Ah effectivement les logs binaire ne gerent pas les "vraies" transaction
ca logue les transactions certes lol
mais j'imaginais que tu pouvais faire un rollback sur une transaction si tu gérais correctement ca ds ton appli
voir la doc transaction, commit, rollback pour voir de quoi je parle
ca aurait été trop beau de pouvoir gérer les retours arrières sur une transaction identifiée par exemple!!
enfin ca doit pouvoir se faire mais c'est certainement pas automatique
y'a pas de flashback ds mysql encore..
Marsh Posté le 09-09-2005 à 21:24:00
avec mysql5, il y a les transactioon en innodb il me semble. A moins que ca soit prévus pour la 5.1, je sais plus. J'ai jamais eu besoin de les utiliser pour le moment.
Mais les transactions ne pouront pas annuler les modifications une fois la transaction validé. Ca n'est que pendant la transaction qu'on peut revenir en arriére. (roolback) Bref, une fois la bétise faite, c'est déjà trop tard pour réparer grâce aux transactions d'autant plus que la transaction, seul le programme qui l'ouvre peut l'annuler ou la valider.
Marsh Posté le 09-09-2005 à 14:09:22
Bonjour,
je travaille actuellement pour mon stage sur un site. Nous sommes actuellement en train de réfléchir sur la facon dont nous pourrions inclure un systeme de log des actions utilisateurs, un truc classique du genre untel a supprimé ceci ou a édité ceci a telle date. Notre probleme est que nous aimerions pouvoir a partir de ce log revenir en arriere. C'est a dire regarder dans le fichier log, voir que tel truc a été supprimé et a partir de la pouvoir le remettre sur le site. Est ce possible et si oui comment en gros cela se met il en place ? Avez vous des idées pour m'orienter dans mes recherches ? Parce que c'est clair qu'on ne peut pas sauvegarder dans une table tout ce que l'on supprime ou édite, ca prendrait une place monstre, mais je ne vois pas comment faire...
Merci