|
|
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Помогите советом или поделитесь опытом кто как делает и как правильнее. Вводная: Аутентификация пользователей происходит на уровне клиентского приложения, а не на уровне базы. И это не может быть изменено. АднАзначнА... Задача: Необходимо вести детальный лог всех действий пользователя, т.е. кто, когда какое поле в какой таблице он изменил. Проблема: Как передать в базу имя пользователя который совершает какое-то действие. Пока что видится такой вариант. В каждую таблицу в которой необходимо отслеживать изменения добавить фиктивное поле "имя пользователя", и навесить на эту таблицу триггеры(триггер) которые и будут писать лог. Но мне как-то не очень нравиться вариант с доп. полем... Других вариантов пока не вижу, похоже зациклился на одном и все... А как еще можно передать переменную в триггер? Может есть более красивые решения? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 10:42:42 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
doroshkaПроблема: Как передать в базу имя пользователя который совершает какое-то действие. CURRENT_USER . Может также пригодиться CURRENT_ROLE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 10:44:50 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий CURRENT_USER . Может также пригодиться CURRENT_ROLE не катит, аутентификация на уровне клиента, а не на уровне СУБД... я тоже только с доп. полем вижу вариант... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 10:54:16 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
doroshkaПомогите советом или поделитесь опытом кто как делает и как правильнее. Вводная: Аутентификация пользователей происходит на уровне клиентского приложения, а не на уровне базы. И это не может быть изменено. АднАзначнА... Все юзеры цепляются к БД под одним логином, что ли ? Почему CURRENT_USER не устраивает ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 10:59:48 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
VF Мимопроходящий CURRENT_USER . Может также пригодиться CURRENT_ROLE не катит, аутентификация на уровне клиента, а не на уровне СУБД... Тогда о каких правах и каком аудите вообще может идти речь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:01:14 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
В FB 1.5 есть CURRENT_CONNECTION Заводишь таблицу с ид_юзера (в вашей системе аутентификации) и номером коннекта. При запуске программы, сразу после аутентификации, добавляешь запись в эту таблицу. Чистишь её когда сам придумаешь ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:01:27 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
2 МП да логгирование там надыть... вон hvlad дело говорит, можно и так наверное... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:09:34 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Да. Я ещё не проснулся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:13:12 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
hvladВ FB 1.5 есть CURRENT_CONNECTION Заводишь таблицу с ид_юзера (в вашей системе аутентификации) и номером коннекта. При запуске программы, сразу после аутентификации, добавляешь запись в эту таблицу. Чистишь её когда сам придумаешь ;) Недопонял. А как же он будет вести автор вести детальный лог всех действий пользователя, т.е. кто, когда какое поле в какой таблице он изменил. Чего триггеры будут в эту самую таблицу писать ? Торможу, что ли... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:16:39 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
AndriyKoЧего триггеры будут в эту самую таблицу писать ? Торможу, что ли... Точно торможу. :-) Пошел пить кофе... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:25:12 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
1. А за логгинг кто у тебя отвечать будет (клинет/сервер)? 2. Пока что видится такой вариант. В каждую таблицу в которой необходимо отслеживать изменения добавить фиктивное поле "имя пользователя", и навесить на эту таблицу триггеры(триггер) которые и будут писать лог. Before Insert/Update/Delete? 3. Может, пусть клиентское приложение все это и делает? Есть такой компонент в FIBPlus - TDataSetsContainer, которы отлавливает все события твоих наборов данных - ну вот, анализируй их, и протоколируй - хочешь в файл, хочешь - в табличку базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:41:27 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
AndriyKoВсе юзеры цепляются к БД под одним логином, что ли ? Да, под SYSDBA. Ситуация такая: есть рабочее место инженера. Он пришел сел за свой комп, запустил прогу, прога законектилась к базе под пользователем SYSDBA, инженер вбил свой пароль прога проверила "да есть такой" и начинает работать. Чтобы не сделал пользователь с базой все это надо отразить в логе (когда какое поле в какой таблице было изменено и на что...). Теперь начинается самое интересное... Чел. уходит покурить и блокирует свое рабочее место (или через n минут оно блокируется само.) При этом коннект к базе остается. К компу подходит другой товарищ. Он может в режиме просмотра работать с базой, но если он вдруг захочет внести изменения, то должен будет ввести свой пароль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:47:11 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
2 mv 1. Хотелось бы чтоб сервер. 2. Угу, только скорее After Insert/Update/Delete 3. Сейчас использую IBX... Да и см. пункт 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:51:22 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
doroshka Чел. уходит покурить и блокирует свое рабочее место (или через n минут оно блокируется само.) При этом коннект к базе остается. К компу подходит другой товарищ. Он может в режиме просмотра работать с базой, но если он вдруг захочет внести изменения, то должен будет ввести свой пароль. В этой ситуации, наверно, самое лучшее, использовать способ, предложенный hvlad - ом. Только в клиенте надо по вводу пароля обязательно пересоединиться к БД (для изменения CURRENT_CONNECTION). Способ логгирования клиентом мне лично не нравится из-за того, что все логи будут раскиданы по разным компам и до кучи их собирать - ну его в баню. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:58:55 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Хе-хе, а перед delete ты специально в свое "дополнительно" поле будешь юзера заносить, чтобы триггер знал, кто удалил запись? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 11:59:32 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
mvХе-хе, а перед delete ты специально в свое "дополнительно" поле будешь юзера заносить, чтобы триггер знал, кто удалил запись? Пока выходит так... :-/ Посмотрю что можно выжать из идеи hvlad-a , за что ему огромное спасибо! с(_) Хотя тут тоже есть небольшое неудобство... У некоторых клиентов до сих пор стоит IB5.6. Но если все забегает с CURRENT_CONNECTION, то будет лишний повод их всех перевести на FB. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 12:07:29 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Представляешь, какая тоска: на каждую табличку по три триггера, и в триггере After Update - каждого поля - а не изменилось ли оно, и запись старого и нового значений? Погляди, к примеру, как IBExpert это делает... А потом извлекать и анализировать всю эту лабуду (не зря же оно протоколировалось)... Между прочим, есть еще способ - каждой протоколируемой таблице поставить в соответсвие ее структурного близнеца (плюс метка времени (если хочешь), версия записи и идентификатор юзера), и при добавлении/изменении/удалении записи пихать туду ВСЮ информацию плюс идентификационные данные. Просто в реализации - то, что ты хочешь, плюс легкая возможность реализации отката... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 12:29:13 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
mvПредставляешь, какая тоска: на каждую табличку по три триггера, и в триггере After Update - каждого поля - а не изменилось ли оно, и запись старого и нового значений? Погляди, к примеру, как IBExpert это делает... А потом извлекать и анализировать всю эту лабуду (не зря же оно протоколировалось)... Естественно надо будет автоматизировать процедуру создания этих триггеров. Возможно и с помощью IBExpert-а Если FB1.5 - то можно один универсальный вешать на табличку. Протоколировать надо для того чтоб начальство знало кому потом надавать по шапке в случае каких-то производственных проблем... mv...каждой протоколируемой таблице поставить в соответсвие ее структурного близнеца ... Спасибо, рассмотрю такой вариант. Проблемму с триггерами - не снимает. Действительно удобно откатываться. Осталось решить надо ли нам это :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.07.2004, 14:19:58 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Можно сделать так таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Идея такова, что при изменении пользователем, у которого есть свой user.id, любой из таблиц БД в таблице action создается строка, содержащая имя изменяемой таблицы, номер изменяемой в ней строки, описание действия пользователя из таблицы action_type (типа, удалил, добавил, изменил), дата и user.id. По такой таблице потом можно будет выводить отчет действий разных пользователей над любой из строк любой из поддерживаемых такой схемой таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2004, 09:33:51 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
2 dreamy Это все понятно... Вопрос в том, как бы все делать централизованно, а не размазывать на 3 х число_таблиц триггеров + анализ значения каждого поля в триггере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2004, 10:59:22 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
mv2 dreamy Это все понятно... Вопрос в том, как бы все делать централизованно, а не размазывать на 3 х число_таблиц триггеров + анализ значения каждого поля в триггере. посмотри как в IBXpert всё это проделано, там в 4 таблицы весь лог пишется, но вот триггеры на каждую таблицу и там поля перечисляются... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2004, 12:45:40 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Об энтом и говорено... Все очень тоскливо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2004, 12:47:14 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Ага, и с паролем masterkey... А потом инженер который что-то не так сделал срочно находит IBE и правит нужные таблички руками скидывая вину на другого юзверя. А вариант по поводу CURERENT_CONNECTION в принципе самый что ни на есть нормальный. Туда и копай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2004, 07:58:19 |
|
||
|
Логирование и/или аудит действий пользователей.
|
|||
|---|---|---|---|
|
#18+
Ну так ясный-красный, что если юзер добрался к базе _не_ через клиентское ПО, то никакие логи ему не страшны. А если он получил физические доступ к базе то и пароли ему тоже не страшны. И как не раз тут говорилось, защита базы от несанкционированного доступа - это забота в первую очередь системного администратора, а в последнюю - СУБД... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2004, 10:24:12 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32614123&tid=1578181]: |
0ms |
get settings: |
5ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
182ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 210ms |
| total: | 464ms |

| 0 / 0 |
