Режим Аудита и как это работает (Agouti)

Первое, есть некоторый опыт работы в сообществах, которые достаточно посещаемые. Мне нравится там система аудит, однако она достаточно своеобразна. Сама логика не особо сложная, но её много. Когда придет понимание, всё логично, но в первые момент ситуация может казаться запутанной.

Аудит

Почему-то не видел подобных вариантов на php. Python, любые другие языки, что угодно, но не php. Странно.

Давайте посмотрим как работает Аудит, на примере Комментариев.

Что вообще происходит, когда пользователь публикует комментарий? Давайте представим ситуацию, что он только зарегистрировался, у него нет комментариев, ответов, постов, ничего нет. И от отвечает.

Пользователь не забанен, он на сайте.

  • Скрипт получает данные из полей и проверят их. Длина там и т.д.

  • Далее проверяет, заморожен ли пользователь. Если заморожен, то редирект на главную и текст объясняющий ситуацию.

  • Далее идет проверка лимитов в зависимости от TL (уровня доверия). У него же нет ничего, в противном случае проверим, и если он вышел за их приделы, то редирект на главную и текст объясняющий ситуацию.

Далее.

  • Скрипт смотрит, его контент содержит URL? Если общий вклад (сумма постов, ответов и комментариев) меньше N, то заморозка (+ оповещение персоналу).

  • Скрипт смотрит, его контент содержит данный из стоп-листа? Если общий вклад (сумма постов, ответов и комментариев) меньше N, то заморозка (+ оповещение персоналу).

Пишу упрощенный режим для понимания Аудита.

Администрации приходит сообщение и он попадает на страницу аудита, где видит следующее.

Аудит на Агути

Собственно 2 кнопки. Он может удалить контент или одобрить.

При одобрении, участник меняет статус с немого режима на обычный и может публиковать дальше. Если нажать удалить, то удалится контент (его можно потом восстановить), а пользователь так и останется в немом режиме.

Идея заключается в том, что персонал должен тратить в 60 раз меньше времени на некоторые вещи по сравнению с участником (а в большинстве случаев, вообще не тратить). Если пользователь регистрируется в течение 1 минуты, то чтобы забанить его необходимо 1 секунда. Пример.

Потоки большие, времени нет чтобы разбираться. Смысл, максимально, что только можно скинуть на систему.

И не просто забанить, но и удалить (скрыть) его контент. Тут нет физического удаление (нам нужна история всего, что происходит).

Лимиты, пределы, будут выставлены в файлах конфигурации, мы сможем менять это дело достаточно гибко. Работы пока много, но начало положено. Возможно эти вещи будут настраиваться не через файлы конфигурации, а более гибко, через админ-интерфейс. Всё может быть.

Далее.

Что такое бан (думаю) писать не стоит, а вот заморозка, это когда участник авторизирован на сайте, но не может совершать активных действий.

Зачем этот режим?

Например, чтобы участник мог воспользоваться личными сообщения, для обратной связи с персоналом сайта. Другие личные сообщения с его стороны, с участниками, блокированы.

Он не может писать посты, отвечать, комментировать, писать личные сообщения другим участникам, только общаться с персоналом. Это одно применение заморозки, есть и другие.

Вчера была добавлена таблица логов (активных действий), теперь есть возможность использовать лимиты более гибко.

P.S. я не писал про правило первого дня, алгоритм, логику, которая позволяет в некоторых сообществах решать в 99% проблему со спамом.

Хакеры используют поведенческие факторы, чтобы выудить некую информацию, тут она используется (и не только тут, например, в форуме Discourse), чтобы предотвратить злоупотребления. Скажу, что достаточно эффективно, если системе уделяется достаточно внимания.

Но она должна быть, чтобы ей заниматься!

Первую часть работ на GitHub разместил, далее продолжим…

7 Ответов

  1. Я смотрел код, там больше условий. Кстати, хотел написать давно, есть возможность провести рефакторинг аудита? Мне код показался сложным.

    1. Сделаем. Он не сложный, не должен быть сложным. А сейчас такой, потому что делал его когда только всё изучал, его упорядочить слегка и будет понятно. Займусь. Спасибо.

  1. А правило первого дня? Есть тут такое?

    1. Дописываю. Это должно быть! Меня больше волнует, что появляется много мелких настроек и взаимодействие меняется. Когда у нас 5 лимитов, то файл конфиг подходит, но когда у нас их за 50, по каждому TL, то необходимо переходить на хранение данных в базе.

  1. В общем необходимо взять и поработать еще над этим. Аудит, флаги. Дело в том, что в MVC насколько я знаю, нет четких указаний, должна ли модель обращаться к другой модели.

    Есть несколько статей по этому поводу, где по большому счету, все сводится к 2 точкам зрения: одни говорит, что это признак плохой архитектуры, а другие, что нет ничего страшного и дело вкуса.

    Но мне не особо нравится это, надо переделать.

  1. В системе жалоб необходимо некоторые переменные обвернуть в Translate, чтобы был перевод. А то с титульной страницы тип выводится на английском языке. )

    1. Да, это сделаю, спасибо +