Есть ли способ временно отключить RateLimiter для массового создания администратором?

Разработка
1

Итак, вот моя проблема. У меня есть требование по сути засевать продакшн-инстанс Discourse примерно 200 постами за раз через действие администратора плагина. Эти посты будут «созданы» одним из 10 обычных пользователей. Причина, по которой это действие плагина, заключается в том, что пользователи этого конкретного инстанса имеют команду модераторов, которых они хотят обучить, и хотели бы иметь тестовые посты для их обучения, а также возможность создавать новые посты по мере необходимости.

У меня это работало отлично, когда я передавал skip_validations: true в PostCreator.new, однако теперь появилось требование, чтобы некоторые из созданных постов также помечались.

Я использую PostActionCreator.create для пометки некоторых из этих постов, но теперь натыкаюсь на ограничитель частоты запросов (rate limiter) здесь: discourse/lib/post_action_creator.rb at ad7a13921f2af8c792530c84386b64911c8e7ea2 · discourse/discourse · GitHub

Сначала я попытался отключить RateLimiter, но это приводило к падению процесса сервера в конечном итоге, возможно, когда я пытался снова включить его, и тогда я понял, что это, вероятно, вообще не хорошая идея.

Так что мой вопрос: есть ли лучший способ обойти ограничитель частоты запросов при выполнении произвольного кода, то есть что-то вроде:

RateLimiter.bypass do
# запуск кода, на который не влияет ограничитель частоты запросов
end

Или мне просто нужно скопировать большую часть того, что делает PostActionCreator, но исключить проблемную строку?

Любая помощь будет очень ценна! Я все еще изучаю код Discourse, поэтому понимаю, что, вероятно, упустил что-то, что могло бы значительно упростить эту задачу!

2

Скорее всего, я бы запустил скрипт в консоли Rails. Вы уже смотрели: Available settings for global rate limits and throttling? Похоже, что эти лимиты скорости можно изменить.

3

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

4

Вы смотрели ссылку об изменении лимитов скорости?

5

Вы уже разобрались? Изменение файла YAML — не лучший вариант, так как это требует пересборки. Я недостаточно хорошо знаком с Rails и Discourse, чтобы понять, как временно отключить это в консоли.

6

Какой у вас случай использования? Какую проблему вы пытаетесь решить, которой мешают ограничения по частоте запросов?

7

Пытаюсь импортировать 60 тысяч пользователей через API максимально быстро, не выполняя перестройку. Также пробовал на тестовой установке увеличить лимит ADMIN API через YAML, но, похоже, это не сработало, хотя, возможно, я что-то сделал неправильно. (Я выполняю импорт в контейнере, поэтому ограничения по HTTP-трафику не должны применяться).

8

Это не очень полезно, но я бы создал пользователей в Rails, а не через API. discourse/script/import_scripts/csv_importer.rb at main · discourse/discourse · GitHub может стать отправной точкой.

Однако вы можете зайти в контейнер, отредактировать файл /var/www/discourse/config/discourse.conf, задать там необходимые переменные, а затем выполнить sv restart unicorn (или, возможно, sv reload unicorn). Скорее всего, вам также понадобится что-то вроде apt-get update; apt-get install -y vim, чтобы установить редактор.

9

Странно. При просмотре конфига новый лимит уже установлен. Значит, обновление YAML сработало:

max_admin_api_reqs_per_key_per_minute = '6000'

Но, похоже, это не работает. Всё ещё действует ограничение в 60 запросов в минуту. Когда я ограничиваю запросы до 60 в минуту, большинство проходит, но из-за джиттера несколько всё же срабатывают на ограничитель скорости:

{'success': True, 'active': True, 'message': 'Ваш аккаунт активирован и готов к использованию.', 'user_id': 3596}
{'success': False, 'message': 'Новые регистрации с вашего IP-адреса не разрешены (достигнут максимальный лимит). Обратитесь к сотруднику.', 'errors': {'ip_address': ['Новые регистрации с вашего IP-адреса не разрешены (достигнут максимальный лимит). Обратитесь к сотруднику.']}, 'values': {'name': None, 'username': 'asdfd', 'email': 'user@domain.com'}, 'is_developer': False}
{'success': True, 'active': True, 'message': 'Ваш аккаунт активирован и готов к использованию.', 'user_id': 3597}
10

Интересно, не проблема ли это с кавычками?

Попробуйте проверить SiteSettings.max_admin_api_reqs_per_key_per_minute и убедитесь, что значение является целым числом.

11

в файле default_current_user_provider.rb (единственном, который, как я нашел, ссылается на это значение), есть:

limit = GlobalSetting.max_admin_api_reqs_per_minute.to_i

так что, похоже, преобразование действительно происходит. Я даже пробовал заменить это значение на число прямо в коде.

12

Чёрт. Я этого и боялся.

13

Я думаю, что это связано с другим ограничением: вероятно, это лимит максимального количества регистраций с одного IP-адреса, который срабатывает, но я не понимаю, почему после его достижения блокировка не становится постоянной. Возможно, это ошибка в этом ограничении спам-регистраций?

14

Если у всех этих пользователей одинаковый IP-адрес, то я готов поспорить, что вы правы. Думаю, решение состоит в том, чтобы изменить эту настройку или выдавать людям поддельные IP-адреса, например 127.0.0.x (или, возможно, использовать IPv6, чтобы упростить задачу?)

15

Думаю, система определяет, откуда сделан запрос (с хост-компьютера), но я могу обойти это, добавив пользователя TL2 с тем же IP-адресом (или изменив лимит по IP.

16

Однако API добавления пользователя работает очень медленно.

17

Вот почему я рекомендую делать это в Rails. Скорее всего, это будет около 500 запросов в минуту.

18

Да, я попробую это сделать. Но я не совсем понимаю, как запускать скрипт: куда его нужно скопировать и как выполнить (после того как я размещу CSV-файл в нужных местах)?

19

Вы можете посмотреть другие темы «Как сделать» для остальных. Они в основном работают одинаково.

20

Как дополнение: учитывая усилия, затраченные на изучение скриптов, Ruby и т. д., а также вероятные проблемы с производительностью, я выбрал другой путь — обошёл все ограничения, записывая данные напрямую в базу данных с помощью SQL. Таким образом мне удалось выполнять несколько тысяч вставок в секунду.

Ранее была тема с вопросом о том, какие таблицы необходимы; сейчас она закрыта, поэтому отвечаю здесь: для вставки пользователей я изменял следующие таблицы:

user_avatars
user_emails
user_profiles
user_search_data
user_stats
users