C'è modo di disattivare temporaneamente il RateLimiter per creazioni di massa dall'amministratore?

Ecco il mio problema. Ho la necessità di popolare un’istanza di Discourse in produzione con circa 200 post alla volta, tramite un’azione amministrativa di un plugin. Questi post saranno ‘creati da’ uno di 10 utenti regolari diversi. Il motivo per cui si tratta di un’azione del plugin è che gli utenti di questa specifica istanza hanno un team di moderatori che vogliono formare e desiderano alcuni post di prova su cui addestrarli, nonché la possibilità di generarne altri quando necessario.

Ho risolto il problema passando skip_validations: true a PostCreator.new, ma ora è richiesto che alcuni dei post creati vengano anche segnalati.

Sto utilizzando PostActionCreator.create per segnalare alcuni di questi post, ma ora vengo bloccato dal limitatore di velocità qui: discourse/lib/post_action_creator.rb at ad7a13921f2af8c792530c84386b64911c8e7ea2 · discourse/discourse · GitHub

Ho prima tentato di disabilitare il RateLimiter, ma ciò ha causato il crash del processo del server alla fine, forse quando cercavo di riattivarlo, e poi ho capito che probabilmente non era comunque una buona idea.

La mia domanda è: esiste un modo migliore per bypassare il limitatore di velocità durante l’esecuzione di codice arbitrario, ad esempio qualcosa del genere:

RateLimiter.bypass do
# esegui del codice non influenzato dal limitatore di velocità
end

Oppure devo semplicemente copiare la maggior parte di ciò che fa PostActionCreator ma omettere la riga problematica?

Qualsiasi aiuto sarebbe molto apprezzato! Sto ancora assorbendo gran parte del codice di Discourse, quindi sono consapevole di aver probabilmente perso qualcosa che renderebbe tutto molto più semplice!

Ciò che probabilmente farei è eseguire uno script nella console di Rails. Hai dato un’occhiata a: Available settings for global rate limits and throttling? Sembra che tu possa modificare quei limiti di velocità.

Non è davvero una strada che voglio percorrere, poiché preferisco che sia avviata dagli utenti, piuttosto che fare affidamento su di me per eseguire uno script nella console.

Hai controllato il link relativo alla modifica dei limiti di velocità?

Hai capito? Modificare il file yaml non è l’ideale perché richiede una ricompilazione. Non ho abbastanza familiarità con rails/discourse per capire come disabilitarlo temporaneamente nella console.

Qual è il tuo caso d’uso? Quale problema stai cercando di risolvere che i limiti di frequenza ti impediscono di affrontare?

Sto cercando di importare 60.000 utenti tramite API il più velocemente possibile senza dover ricostruire. Ho anche provato su un’installazione di test ad aumentare il limite dell’API ADMIN tramite YAML, ma non sembrava funzionare, ma forse ho fatto qualcosa di sbagliato. (Sto eseguendo le importazioni sul container, quindi il throttling HTTP non dovrebbe applicarsi).

Questo non è molto utile, ma quello che farei è creare gli utenti in Rails piuttosto che tramite l’API. discourse/script/import_scripts/csv_importer.rb at main · discourse/discourse · GitHub potrebbe essere un inizio.

Ma puoi entrare nel container e modificare /var/www/discourse/config/discourse.conf e impostare quelle variabili lì e poi fare un sv restart unicorn (o forse sv reload unicorn). Probabilmente vorrai fare qualcosa come apt-get update; apt-get install -y vim per avere un editor.

Strano. Quando visualizzo il file di configurazione, il nuovo limite è già impostato. Quindi l’aggiornamento YAML ha funzionato:

max_admin_api_reqs_per_key_per_minute = '6000'

Ma non sembra funzionare. C’è ancora una limitazione di 60 al minuto. Quando limito le richieste a 60 al minuto, la maggior parte passa ma a causa del jitter alcune attivano ancora il rate limiter:

{'success': True, 'active': True, 'message': 'Il tuo account è stato attivato e pronto per l'uso.', 'user_id': 3596}
{'success': False, 'message': ' Le nuove registrazioni non sono consentite dal tuo indirizzo IP (limite massimo raggiunto). Contatta un membro dello staff.', 'errors': {'ip_address': ['Le nuove registrazioni non sono consentite dal tuo indirizzo IP (limite massimo raggiunto). Contatta un membro dello staff.']}, 'values': {'name': None, 'username': 'asdfd', 'email': 'user@domain.com'}, 'is_developer': False}
{'success': True, 'active': True, 'message': 'Il tuo account è stato attivato e pronto per l'uso.', 'user_id': 3597}

Mi chiedo se sia un problema con le virgolette?

Potresti controllare SiteSettings.max_admin_api_reqs_per_key_per_minute e vedere se è un intero

in default_current_user_provider.rb (l’unico file che ho trovato che sembrava fare riferimento a questo valore, contiene:

limit = GlobalSetting.max_admin_api_reqs_per_minute.to_i

quindi sembra convertirlo. Ho anche provato a sostituirlo con un numero nel codice.

Accidenti. Temevo che fosse così.

Penso che sia correlato a un altro limite: penso che sia il limite massimo di registrazioni da un IP che sta raggiungendo, ma non capisco perché dopo aver raggiunto questo limite non blocchi permanentemente. Possibilmente un bug in questo limite anti-spam?

Se tutti quegli utenti hanno lo stesso IP, allora scommetto che hai ragione. Penso che la soluzione sia cambiare quell’impostazione o dare alle persone indirizzi IP fasulli come 127.0.0.x (o forse usare IPv6 per renderlo più facile?)

Penso che stia rilevando da dove viene effettuata la richiesta (computer host), ma posso aggirarlo aggiungendo un utente TL2 sullo stesso indirizzo IP (o modificare il limite IP).

L’API dell’utente è molto lenta, però.

Ecco perché consiglio di farlo in Rails. Probabilmente farà circa 500 al minuto.

Sì, ci proverò. Ma non mi è chiaro come dovrei eseguire lo script, dove devo copiarlo e come devo eseguirlo (una volta che avrò messo il CSV nei posti giusti)?

Puoi consultare altri argomenti su come fare per gli altri. Funzionano quasi tutti allo stesso modo.

Come follow-up, dato lo sforzo per comprendere gli script e Ruby, ecc. e le probabili prestazioni, ho intrapreso un’altra strada e ho aggirato tutti i limiti scrivendo direttamente nel database usando SQL. In questo modo sono stato in grado di ottenere diverse migliaia di inserimenti al secondo.

C’era un argomento che chiedeva quali tabelle fossero necessarie, ora è chiuso, quindi rispondo qui che ho modificato le seguenti tabelle per inserire gli utenti:

user_avatars
user_emails
user_profiles
user_search_data
user_stats
users