Voici mon problème. J’ai besoin de générer environ 200 posts à la fois sur une instance Discourse en production, via une action d’administration de plugin. Ces posts seront « créés par » l’un des 10 utilisateurs réguliers. La raison pour laquelle il s’agit d’une action de plugin est que les utilisateurs de cette instance spécifique disposent d’une équipe de modérateurs qu’ils souhaitent former, et ils ont besoin de quelques posts de test pour les entraîner, ainsi que de la possibilité d’en générer davantage au besoin.
J’ai réussi à faire fonctionner cela en passant skip_validations: true à PostCreator.new, mais maintenant, il est requis que certains des posts créés soient également signalés.
J’ai d’abord tenté de désactiver le RateLimiter, mais cela a fini par faire planter le processus du serveur, peut-être lorsque j’essayais de le réactiver, et j’ai ensuite réalisé que ce n’était probablement pas une bonne idée de toute façon.
Ma question est donc : existe-t-il une meilleure façon de contourner le limiteur de débit lors de l’exécution d’un code arbitraire, c’est-à-dire quelque chose comme :
RateLimiter.bypass do
# exécuter du code non affecté par le limiteur de débit
end
Ou dois-je essentiellement copier la majeure partie du code de PostActionCreator mais en omettant la ligne problématique ?
Toute aide serait grandement appréciée ! Je suis encore en train d’assimiler beaucoup de choses dans le code de Discourse, donc je suis conscient d’avoir probablement manqué quelque chose qui rendrait cela beaucoup plus simple !
Ce n’est pas vraiment une voie que je souhaite emprunter, car je souhaite que ce soit initié par les utilisateurs plutôt que de dépendre de moi pour exécuter un script dans la console.
Avez-vous trouvé une solution ? Modifier le fichier yaml n’est pas idéal car cela nécessite une reconstruction. Je ne suis pas assez familier avec rails/discourse pour savoir comment le désactiver temporairement dans la console.
J’essaie d’importer 60 000 utilisateurs via l’API aussi rapidement que possible sans reconstruire. J’ai également essayé sur une installation de test d’augmenter la limite de l’API ADMIN via YAML, mais cela n’a pas semblé fonctionner, mais peut-être que j’ai mal fait quelque chose. (J’exécute les importations sur le conteneur, donc la limitation HTTP ne devrait pas s’appliquer).
Mais vous pouvez entrer dans le conteneur et modifier /var/www/discourse/config/discourse.conf et y définir ces variables, puis faire un sv restart unicorn (ou peut-être sv reload unicorn). Vous voudrez probablement faire quelque chose comme apt-get update; apt-get install -y vim pour avoir un éditeur.
Étrange. Lorsque j’affiche le fichier de configuration, la nouvelle limite est déjà définie. La mise à jour YAML a donc fonctionné :
max_admin_api_reqs_per_key_per_minute = '6000'
Mais cela ne semble pas fonctionner. Il y a toujours une limitation de 60 par minute. Lorsque je limite les requêtes à 60 par minute, la plupart passent, mais en raison de la gigue, quelques-unes déclenchent toujours le limiteur de débit :
{'success': True, 'active': True, 'message': 'Your account is activated and ready to use.', 'user_id': 3596}
{'success': False, 'message': ' New registrations are not allowed from your IP address (maximum limit reached). Contact a staff member.', 'errors': {'ip_address': ['New registrations are not allowed from your IP address (maximum limit reached). Contact a staff member.']}, 'values': {'name': None, 'username': 'asdfd', 'email': 'user@domain.com'}, 'is_developer': False}
{'success': True, 'active': True, 'message': 'Your account is activated and ready to use.', 'user_id': 3597}
Je pense que c’est lié à une autre limite : je pense que c’est la limite d’enregistrements maximum à partir d’une adresse IP qui est atteinte, mais je ne comprends pas pourquoi elle ne bloque pas définitivement après l’avoir atteinte. S’agit-il potentiellement d’un bug dans cette limite anti-spam ?
Si ces utilisateurs ont tous la même adresse IP, alors je parie que vous avez raison. Je pense que la solution est de modifier ce paramètre ou de donner aux gens des adresses IP bidon comme 127.0.0.x (ou peut-être utiliser IPv6 pour faciliter les choses ?)
Je pense qu’il détecte d’où la requête est faite (ordinateur hôte) mais je peux contourner cela en ajoutant un utilisateur TL2 sur la même adresse IP (ou en ajustant la limite d’IP).
Oui, je vais essayer ça. Mais je ne suis pas sûr de la façon dont je suis censé exécuter le script, où dois-je le copier et comment l’exécuter (une fois que j’aurai mis le CSV aux bons endroits) ?
Pour faire suite à l’effort de compréhension des scripts et de Ruby, etc., et compte tenu des performances probables, j’ai choisi une autre voie et j’ai contourné toutes les limites en écrivant directement dans la base de données en utilisant SQL. De cette façon, j’ai pu effectuer plusieurs milliers d’insertions par seconde.
Il y avait un sujet demandant quelles tables étaient nécessaires, il est maintenant fermé, donc je réponds ici que j’ai modifié les tables suivantes pour insérer les utilisateurs :