Merci beaucoup ! Oui, je vais faire ça ! Je recherche spécifiquement les pages vues (utilisateurs connectés, utilisateurs anonymes, robots d’indexation) mais je ne trouve pas cette information dans la documentation de l’API. Des indications ?
Certains appels spécifiques à l’administration ne figurent pas dans la documentation de l’API
J’ouvrirais l’onglet réseau, j’irais sur la page d’administration, je visionnerais le rapport avec les données que vous souhaitez récupérer, puis je vérifierais l’onglet réseau pour voir ce que le navigateur a chargé.
Ce qui est en fait un résumé de Reverse engineer the Discourse API
Ce que je ferais, c’est utiliser le plugin Data Explorer pour obtenir ce que vous voulez, puis vous pouvez le récupérer avec l’API. Exécuter des requêtes Data Explorer avec l’API Discourse
Absolument ; si vous souhaitez des données différentes de celles déjà proposées dans le panneau d’administration, DE est la voie à suivre.
Cela garantit également que ces requêtes ne renverront pas de données différentes après une mise à jour, MAIS les structures sous-jacentes peuvent également changer et vous pourriez avoir besoin de maintenir la requête.
Compromis dans tous les cas.
Merci à vous deux ! J’ai réussi avec la méthode de la « rétro-ingénierie » + clé API ! Merci beaucoup !
Un peu en retard sur cette conversation (bon, sur sa suite :p), mais je voulais aussi extraire des données d’un forum Discourse sans avoir la corvée de configurer une clé API. Si vous (ou n’importe qui) souhaitez un simple wrapper pour récupérer des publications depuis n’importe quel forum Discourse, vous pouvez le consulter ici.
Disponible sur PyPI, donc facile à installer avec pip/uv, il gère automatiquement la limitation de débit et est typé avec Pydantic (ce qui améliore l’expérience développeur, à mon avis). Utilisation :
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# Parcourir les catégories
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} sujets")
# Récupérer un sujet avec tous ses messages
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # le message original (HTML)
print(topic.accepted_answer) # réponse acceptée ou None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
Ce n’est pas aussi complet que pydiscourse, mais c’est intentionnel puisqu’il fonctionne sans clé API. Il ne proposera certainement pas de données meilleures ou plus rapides que le plugin Data Explorer, mais je trouve que c’est pratique si vous voulez simplement récupérer rapidement un lot de fils de discussion ou des statistiques simples du site 
J’ai l’impression que cette approche pourrait violer les conditions d’utilisation de ce forum ainsi que les conditions d’utilisation par défaut des forums Discourse.
Vous n’êtes pas autorisé à automatiser l’accès au forum ni à le surveiller, par exemple à l’aide d’un robot d’indexation web, d’un module ou d’une extension de navigateur, ou de tout autre programme informatique qui n’est pas un navigateur web. Vous pouvez toutefois crawler le forum pour l’indexer dans un moteur de recherche accessible au public, si vous en exploitez un.
Hmm. Je ne pense pas faire quelque chose de particulier au-delà d’encapsuler simplement ce qui serait autrement une requête curl simple vers l’un des points de terminaison API documentés publiquement. Cependant, si l’équipe @Discourse se sent offensée par ce que j’ai créé, veuillez me le faire savoir.
Personnellement, je ne pense pas que le package lui-même viole les conditions d’utilisation (ToS), car la responsabilité de respecter les conditions d’un forum revient toujours au développeur qui utilise l’outil. Ce package ne fait appel qu’à des points de terminaison API publics et documentés ; si un développeur a une intention malveillante de scraper ou de surveiller un forum, cela serait déjà, honnêtement, une tâche triviale.
Sur ce point, pydiscourse offre la même fonctionnalité, la seule différence étant la nécessité d’une clé API (je ne sais pas à quel point c’est facile à faire pour un utilisateur régulier), après quoi il peut également être utilisé pour violer les conditions d’utilisation de n’importe quel forum. Donc, si la règle par défaut est de ne pas automatiser l’accès au forum, est-ce que pydiscourse et discourse2 ne violeraient pas également les ToS ? discourse2 annonce même l’accès aux données accessibles publiquement dans sa liste de fonctionnalités si aucune clé API n’est fournie :
Fonctionne à la fois dans les environnements serveur et navigateur* (*utile pour interroger des données publiques sans clés API et sur l’origine pertinente, par exemple les derniers sujets, etc.)
Il existe probablement beaucoup d’autres packages dans d’autres langues qui prennent déjà en charge ce type d’accès.
Quelques précisions : j’ai créé cela pour pouvoir facilement extraire des données d’un forum hébergé par l’un de nos clients (mais nous n’avons pas d’accès direct à la base de données). Cela rend simplement mon flux de travail plus propre, et j’espère aider d’autres personnes qui se trouvent dans la même situation.
Le problème est que la génération d’une clé API nécessite d’abord un accès à l’interface d’administration (Admin > Avancé > Clés API). Ainsi, attribuer une clé API est quelque chose que les administrateurs veulent faire ; aucun utilisateur ordinaire ne peut en obtenir une.
Oui, si la seule façon d’obtenir une clé API est via l’interface d’administration, alors ce paquet pourrait simplifier la violation des CGU d’un forum spécifique.
Cependant, je souhaite toujours discuter de certains autres points que j’ai soulevés et connaître l’avis des autres à leur sujet, à savoir : N’importe qui pouvait déjà facilement scraper ou surveiller avec curl ou requests. La responsabilité ne devrait-elle pas incomber au développeur pour qu’il ne viole pas les CGU ? Ou devrait-elle incomber aux outils qu’il a utilisés eux-mêmes ?
Pour discourse2 et des paquets similaires, ils ont des objectifs plus larges, mais discourse2 continue de mettre en avant la possibilité de fonctionner sur des points de terminaison publics si aucune clé API n’est fournie. Est-ce que cela permet de violer les CGU au même degré ?
En outre, puisque Discourse est sous licence GPLv2, la création d’un outil comme discourse-reader viole-t-elle intrinsèquement directement certains termes ?
Curieux d’entendre l’avis des autres sur ces questions.
Le gem Ruby officiel discourse_api prend également en charge l’accès aux données publiques sans clé API. Je pense donc qu’il est acceptable que cet outil existe. C’est aux utilisateurs de s’assurer qu’ils respectent les conditions d’utilisation spécifiques à chaque forum.
(Ceci est mon opinion personnelle, pas une déclaration juridique officielle de CDCK 
)
Il est également important de noter que les requêtes de « bots » non authentifiés sont soumises à des limites de débit beaucoup plus strictes, ainsi qu’à d’autres couches de sécurité de protection contre les « bots » (par exemple Cloudflare). Donc, si possible, il est toujours préférable d’utiliser une clé API.
Merci pour ta réponse ! Pour le moment, j’ai mis à jour le README de mon paquet en ajoutant une mention indiquant qu’il faut respecter les CGU du site que tout développeur pourrait souhaiter cibler.
Je n’étais pas du tout au courant de cette règle par défaut des CGU au moment où j’ai créé cela. J’espère que toute personne qui envisage d’utiliser ce paquet en apprendra aussi à l’avenir
Oui, cela fait écho aux arguments avancés pour les magnétoscopes… il y a un certain temps. De même pour les crochets de serrure. Il existe des utilisations légitimes et illégitimes des outils, et c’est à l’opérateur d’en assumer la responsabilité.
Encore une fois, je ne suis pas avocat et ceci ne constitue pas une déclaration officielle, mais je pense que cela reflète fidèlement notre point de vue :
Il y a une grande différence entre une exploration bien intentionnée à l’aide d’un outil (par exemple) et la mise en place d’une automatisation.
Nous ne nous fâcherons pas avec les personnes utilisant des outils comme celui-ci sur Meta, surtout s’ils développent des fonctionnalités ou apprennent à interagir avec l’API Discourse. Nous l’encouragerons, tant que vous ne faites pas de scraping massif de données, n’imposez pas de charge excessive et ne dégradez pas l’expérience des autres.