Очистить user_auth_token_logs?

Внести вклад Ошибка
1

У нас есть форум, где в таблице user_auth_token_logs 61 миллион записей (и их число продолжает расти).

Всего существует 25 тысяч user_auth_tokens.

Из 61 миллиона записей 54 миллиона ссылаются на user_auth_token, который больше не существует (т. е. это проблема целостности базы данных). Из 61 миллиона записей около 58 миллионов имеют дату создания старше двух месяцев (т. е. они, по-видимому, бесполезны?).

Вопросы:

  • Можем ли мы просто очистить эти данные, не рискуя вызвать дальнейшие проблемы с целостностью?
  • Было бы хорошей идеей создать задачу для автоматической очистки?
db=# select count(*) from user_auth_tokens;
 count 
-------
 25648

db=# select count(*) from user_auth_token_logs;
  count   
----------
 61415352

db=# select count(*) from user_auth_token_logs where user_auth_token_id not in (select id from user_auth_tokens);
  count   
----------
 54558442

db=# select count(*) from user_auth_token_logs where created_at < '2024-07-13';
  count   
----------
 58565943
4 лайка
How can I get the current version information from my backup?
3

Да, user_auth_token_logs существуют только для отладки. Все строки можно удалить, единственное последствие — у вас не будет журналов для отладки.

Это должно быть покрыто здесь:

https://github.com/discourse/discourse/blob/main/app/jobs/scheduled/weekly.rb#L13

2 лайка
5

Спасибо, я не знал об этом.

Так… очистка выполняется только когда verbose_auth_token_logging установлен в true (что в данном случае не так),

но не подробное логирование происходит всегда, независимо от настройки :scream:

согласно 8fb823c

Переношу это в bug :slight_smile:

4 лайка
6

Ах да, верно подмечено. Похоже, что строки 214–217 тоже нужно исправить.

Я бы согласился с глобальной очисткой после определённого промежутка времени. @osama (поскольку вы автор коммита, на который приведена ссылка выше), как вы думаете, можно ли очищать все эти логи через какое-то время (и если да, то через сколько)? Похоже, что некоторые из них нужно сохранять для обнаружения подозрительных входов в систему.

4 лайка
7

Почему это нужно исправить? :thinking: Этот фрагмент кода касается очистки ротированных UserAuthToken, а не записей в логе?

Обновление: после включения SiteSetting.verbose_auth_token_logging, запуска недельной задачи и выполнения VACUUM FULL user_auth_token_logs размер таблицы уменьшился с 16 ГБ до 687 МБ :+1:

Сегодня спасли несколько деревьев :deciduous_tree:

3 лайка
8

Да, я думаю, что мы можем удалить большинство логов, но некоторые должны остаться. В частности, я считаю, что любые записи с действиями suspicious, generate или rotate нужно сохранять, так как они используются для обнаружения подозрительных входов и формирования отчётов по ним.

3 лайка
12

На моём форуме я вижу, что эта ошибка так и не была исправлена :eyes:

Отчёт о подозрительных входах, похоже, применяется только к сотрудникам. Есть ли причина, по которой эти логи нужно хранить для неадминистраторов?

Для работы отчёта необходимы ли данные с самого начала истории аккаунта? Можно ли сократить лог, например, до последних 6 месяцев?

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

2 лайка
13

Я тоже не понимаю обсуждение выше.

Ошибка очень проста: если режим не детальный, очистка UserAuthTokenLog вообще никогда не выполняется. Условие if нужно убрать.

image
image500×259 5.06 KB

В исходной реализации логирование происходило только при значении SiteSetting.verbose_auth_token_logging равном true. Это всё ещё имело проблему: после отключения в логах оставались самые последние записи, но это мелочь.

Однако это изменение сделало логирование безусловным (“Журналы аутентификационных токенов generate, rotate и suspicious теперь всегда записываются, независимо от настройки verbose_auth_token_logging”).

TLDR; В том изменении забыли сделать удаление также безусловным.

3 лайка
14

Конечно, мы разберёмся с этим в ближайшие несколько недель. Если спешите, не стесняйтесь прислать pull request (проверенный и подтверждающий, что всё работает как ожидалось).

1 лайк
17

Я сделал PR Fix: cleanup UserAuthTokenLog unconditionally by communiteq · Pull Request #34288 · discourse/discourse · GitHub, было бы здорово, если бы это вошло в релиз 3.5

19

Похоже, меня опередили :slight_smile:
https://github.com/discourse/discourse/pull/34196/commits

2 лайка
20

Действительно, этот PR теперь объединён благодаря @Osama. Он охватывает большинство типов user_auth_token_logs, но не все. Мы скоро подготовим исправление для записей generate. (Более подробный контекст см. в обсуждении по ссылке на PR выше).

Я оставлю эту тему открытой, пока мы не решим вопрос с последующим исправлением.

4 лайка