Gibt es eine Möglichkeit, den RateLimiter für eine kurzfristige Massenbefüllung durch den Administrator vorübergehend zu deaktivieren?

Entwickler
1

Also hier ist mein Problem. Ich habe die Anforderung, eine Discourse-Produktionsinstanz im Wesentlichen mit jeweils etwa 200 Beiträgen aus einer Plugin-Admin-Aktion zu füllen. Diese Beiträge werden von einem von zehn verschiedenen regulären Benutzern erstellt. Der Grund, warum dies eine Plugin-Aktion ist, liegt darin, dass die Benutzer dieser speziellen Instanz ein Team von Moderatoren haben, das sie ausbilden möchten, und sie einige Testbeiträge zum Trainieren sowie die Möglichkeit benötigten, bei Bedarf weitere zu generieren.

Ich habe dies problemlos gelöst, indem ich skip_validations: true an PostCreator.new übergeben habe. Nun gibt es jedoch die Anforderung, dass einige der erstellten Beiträge auch gemeldet werden sollen.

Ich verwende PostActionCreator.create, um einige dieser Beiträge zu melden, stoße dabei aber auf den Rate-Limiter hier: discourse/lib/post_action_creator.rb at ad7a13921f2af8c792530c84386b64911c8e7ea2 · discourse/discourse · GitHub

Ich habe zunächst versucht, den RateLimiter zu deaktivieren, was jedoch dazu führte, dass mein Aktion den Server-Prozess schließlich abstürzen ließ, möglicherweise als ich versuchte, ihn wieder zu aktivieren. Dann wurde mir klar, dass dies ohnehin wahrscheinlich keine gute Idee war.

Meine Frage ist also: Gibt es einen besseren Weg, den Rate-Limiter zu umgehen, wenn man einen beliebigen Code ausführt, also so etwas wie:

RateLimiter.bypass do
# Führe Code aus, der nicht vom Rate-Limiter betroffen ist
end

Oder muss ich im Grunde genommen nur den Großteil dessen kopieren, was PostActionCreator tut, und die problematische Zeile weglassen?

Jede Hilfe wäre sehr geschätzt! Ich bin noch dabei, einen Großteil des Discourse-Codes zu verstehen, daher ist mir bewusst, dass ich wahrscheinlich etwas übersehen habe, was dies erheblich vereinfachen würde!

2

Was ich wahrscheinlich tun würde, ist ein Skript in der Rails-Konsole ausführen. Hast du dir bereits das Folgende angesehen: Available settings for global rate limits and throttling? Es scheint, als könnten du diese Ratenbegrenzungen ändern.

3

Das ist nicht wirklich der Weg, den ich gehen möchte, da ich möchte, dass die Nutzer dies selbst initiieren, anstatt sich darauf zu verlassen, dass ich ein Skript in der Konsole ausführe.

4

Hast du dir den Link zu den Änderungen der Ratenlimits angesehen?

5

Haben Sie das herausgefunden? Das Ändern der YAML-Datei ist nicht ideal, da es einen Neuerstellungsprozess erfordert. Ich bin nicht vertraut genug mit Rails/Discourse, um herauszufinden, wie man es vorübergehend in der Konsole deaktiviert.

6

Was ist Ihr Anwendungsfall? Welches Problem versuchen Sie zu lösen, das durch Ratenbegrenzungen behindert wird?

7

Ich versuche, 60.000 Benutzer so schnell wie möglich über die API zu importieren, ohne einen Neuaufbau durchzuführen. Ich habe auch auf einer Testinstallation versucht, das ADMIN-API-Limit über YAML zu erhöhen, aber es schien nicht zu funktionieren, aber vielleicht habe ich etwas falsch gemacht. (Ich führe Importe im Container durch, sodass die HTTP-Drosselung nicht gelten sollte).

8

Das ist nicht sehr hilfreich, aber was ich tun würde, wäre, die Benutzer in Rails zu erstellen und nicht über die API. discourse/script/import_scripts/csv_importer.rb at main · discourse/discourse · GitHub könnte ein Anfang sein.

Aber Sie können in den Container gehen und /var/www/discourse/config/discourse.conf bearbeiten und diese Variablen dort setzen und dann ein sv restart unicorn (oder vielleicht sv reload unicorn) ausführen. Sie möchten wahrscheinlich etwas wie apt-get update; apt-get install -y vim tun, um einen Editor zu haben.

9

Seltsam. Wenn ich die Konfigurationsdatei ansehe, ist das neue Limit bereits gesetzt. Das YAML-Update hat also funktioniert:

max_admin_api_reqs_per_key_per_minute = '6000'

Aber es scheint nicht zu funktionieren. Es gibt immer noch eine Begrenzung von 60 pro Minute. Wenn ich Anfragen auf 60 pro Minute drossle, gehen die meisten durch, aber aufgrund von Jitter lösen einige immer noch den Ratenbegrenzer aus:

{'success': True, 'active': True, 'message': 'Ihr Konto ist aktiviert und einsatzbereit.', 'user_id': 3596}
{'success': False, 'message': 'Neue Registrierungen sind von Ihrer IP-Adresse nicht erlaubt (maximales Limit erreicht). Kontaktieren Sie einen Mitarbeiter.', 'errors': {'ip_address': ['Neue Registrierungen sind von Ihrer IP-Adresse nicht erlaubt (maximales Limit erreicht). Kontaktieren Sie einen Mitarbeiter.']}, 'values': {'name': None, 'username': 'asdfd', 'email': 'user@domain.com'}, 'is_developer': False}
{'success': True, 'active': True, 'message': 'Ihr Konto ist aktiviert und einsatzbereit.', 'user_id': 3597}
10

Ich frage mich, ob es ein Problem mit den Anführungszeichen ist?

Sie könnten SiteSettings.max_admin_api_reqs_per_key_per_minute überprüfen und sehen, ob es eine Ganzzahl ist.

11

in default_current_user_provider.rb (die einzige Datei, die ich gefunden habe, die auf diesen Wert zu verweisen schien, enthält:

limit = GlobalSetting.max_admin_api_reqs_per_minute.to_i

es scheint ihn also zu konvertieren. Ich habe sogar versucht, ihn durch eine Zahl im Code zu ersetzen.

12

Mist. Das habe ich befürchtet.

13

Ich glaube, es hängt mit einem anderen Limit zusammen: Ich denke, es ist das Limit für die maximale Anzahl von Registrierungen von einer IP-Adresse, das erreicht wird, aber ich verstehe nicht, warum es nach dem Erreichen dieses Limits nicht dauerhaft blockiert wird. Möglicherweise ein Fehler in diesem Spam-Limit?

14

Wenn all diese Nutzer dieselbe IP-Adresse haben, dann liegst du wahrscheinlich richtig. Ich denke, die Lösung ist, diese Einstellung zu ändern oder den Leuten gefälschte IP-Adressen wie 127.0.0.x zu geben (oder vielleicht IPv6 zu verwenden, um es einfacher zu machen?).

15

Ich glaube, es erkennt, wo die Anfrage gestellt wird (Host-Computer), aber ich kann es umgehen, indem ich einen TL2-Benutzer mit derselben IP-Adresse hinzufüge (oder das IP-Limit anpasse).

16

Die API des Nutzers ist jedoch sehr langsam.

17

Deshalb empfehle ich, es in Rails zu tun. Es wird wahrscheinlich etwa 500 pro Minute schaffen.

18

Ja, das werde ich versuchen. Aber mir ist nicht klar, wie ich das Skript ausführen soll, wohin ich es kopieren soll und wie ich es ausführen soll (sobald ich die CSV-Dateien an den richtigen Stellen platziert habe)?

19

Sie können sich einige der anderen Anleitungs-Themen für die anderen ansehen. Sie funktionieren fast alle gleich.

20

Als Nachtrag, angesichts des Aufwands, die Skripte und Ruby usw. zu verstehen, und der wahrscheinlichen Leistung, habe ich einen anderen Weg eingeschlagen und alle Limits umgangen, indem ich direkt mit SQL in die Datenbank geschrieben habe. Auf diese Weise konnte ich mehrere tausend Einfügungen pro Sekunde erzielen.

Es gab ein Thema, in dem gefragt wurde, welche Tabellen benötigt werden. Es ist jetzt geschlossen, daher antworte ich hier, dass ich die folgenden Tabellen geändert habe, um die Benutzer einzufügen:

user_avatars
user_emails
user_profiles
user_search_data
user_stats
users