| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Сохранение логов. |
| Автор: BuShaRt 18.5.2007, 10:10 |
| К имеющемуся проекту потребовался логер, понятный пользователю. И вот передо мной встал вопрос, а как организовать такой логгер. Единственное, что я точно определил, что там должны будет храниться не только системные сообщения и запросы в БД, но и понятные пользователю сообщения т.е. он не знает даже, что такое База данных. 1. Основные модерациооные действия происходят через запрос к базе данных. Так вот, хватит ли мне для полного контроля сохранять все операции с БД и файлами. Или есть еще функции, которые следует контролировать? 2. Сколько по времени следует хранить логии? 3. Где стоит хранить логии? Записей много, а модерация самая элементарная. 4. Как их стоит представлять пользователю? Должен отметить, что логии будут просматриваться не в ручную, конечно для этого будет специальный модуль. |
| Автор: WolfON 18.5.2007, 11:57 |
| В идеальной реализации системы логирования будут использоваться Аспектно-Ориентированное программирование и Syslog или БД http://phpaspect.org/ http://ru2.php.net/syslog |
| Автор: BuShaRt 18.5.2007, 12:17 |
| WolfON, Английского мы не знаем :( |
| Автор: WolfON 18.5.2007, 13:02 |
| BuShaRt, а очень-очень зря. хороший документации по аспектно-ориентированному программированию на русском языке я не находил. сама эта парадигма, на мой взгляд очень перспективна в создании такого функционала, вроде систем поиска, логирования, обеспечения безопасности и тд. Можешь почитать вот это: http://www.cmsdevelopment.com/ru/articles/aosdinphp/ Чтобы не отдаляться от темы, то скажу, что если не нужны особо навороченные фичи и все-такое, то почему-бы просто не перехватывать все запросы на уровне абстракции баз данных, анализировать их и затем всю нужную информацию писать куда надо (через тот-же syslog допустим). |
| Автор: WolfON 18.5.2007, 17:22 |
| Если так, то можно создать триггер в БД на добавление полей, который дополнительную информацию будет записывать в отдельную таблицу. Или просто писать дополнительную информацию рядом с основной - в скорости от этого не убудет, зато потом можно быстро создавать всякие-разные отчеты. Как реализовать в коде я идею уже кинул, если, конечно, делать серьезный логгер. А простой можно и просто выделить пару функций на уровне абстракции бд, а можно и класс написать - тут уж на вкус и цвет.. Подводные камни - потеря производительности. Особенно при использовании БД (лишний инсерт - дорогая операция в мускуле), по этому самое оптимальное решение syslog - за эффективное хранение информации тут будет отвечать непосредственно система. Да и вообщем-то для ведения логов хватает самого обычного текстового файла. |
| Автор: BuShaRt 18.5.2007, 17:54 |
| WolfON, А по времени сколько желательно хранить логи? Ведь по суте я думаю если стереть отчеты месячной давности, то от безопастности не не убудет? Или я ошибаюсь? |
| Автор: WolfON 18.5.2007, 18:13 |
| BuShaRt, ну это уже ваше личное дело ) Можно месяц, можно два, а можно вообще не удалять. Компромисс - месяц хранить, а потом в архив |
| Автор: BuShaRt 18.5.2007, 18:24 |
| WolfON, Ясно.. спасибо |
| Автор: MoLeX 19.5.2007, 08:33 |
| ЛОГИ!!! я не совсем понял что тебе нужно!!! Если нужно просматривать что именно вводил пользователь в адресной строке (пример: http:⁄⁄mysite.ru⁄index.php?page=<script>alert(‘XSS’)</script>) т.е. для быстрого выяснения через какой баг ваш сайт взломали советую поставить замечательны скрипт носящий название - http://www.cnstats.com/, он нетока тебе все покажет но и расскажет какой ипи, во ско-ко... короче поставь и посмотри... непожалеешь.... |
| Автор: BuShaRt 19.5.2007, 11:42 |
| MoLeX, нет, журал действий модераторов... Дабы проследить дыру в безопастности созданную человеческим фактором т.е. отгородиться от соц. инжинеров. |
| Автор: WolfON 19.5.2007, 14:28 |
| BuShaRt, от человеческого фактора практически невозможно защититься, но есть возможность "догадаться" о взломе. Самый очевидный - при создании отчета выставлять каждому действию или группе действий - степень опасности. Т.е допустим клиент заходит с ip из одной подсети - это нормальное действие у него 0 опасности, но если вдруг пользователь заходит с ip из другой подсети, то ему можно выставить 5 уровень опасности - возможно, что это не он заходит. Или если пользователь часто логиниться, то этим действием тоже выставляется повышенный уровень опасности - допустим 3. В итоге можно получить таблицу пользователей с уровнем опасности для каждого и таблицу действий. Ориентируясь на уровень опасности можно уже принимать какие-нибудь меры, допустим принудительная смена пароля. |
| Автор: BuShaRt 19.5.2007, 20:53 |
| WolfON, Наверно логичней всего продумывать логер под определенный проект. Т.к. вами редставленно средство нелогично в пределах админ системы сайта магазина. З.ы. именно сайта магазина, а не сайта-магазина. |