Vielen Dank! Ja, das werde ich tun! Ich suche speziell nach Seitenaufrufen (angemeldete Benutzer, anonyme Benutzer, Crawler), kann dies aber in der API-Dokumentation nicht finden. Irgendwelche Hinweise?
Einige der Admin-spezifischen Aufrufe sind nicht in der API-Dokumentation aufgeführt.
Ich würde die Netzwerk-Registerkarte öffnen, zur Admin-Seite gehen, den Bericht mit den Daten anzeigen, die Sie abrufen möchten, und dann die Netzwerk-Registerkarte überprüfen, um zu sehen, was der Browser geladen hat.
Was im Grunde eine Zusammenfassung von Reverse engineer the Discourse API ist.
Was ich tun würde, ist, das Data Explorer-Plugin zu verwenden, um alles zu erhalten, was Sie möchten, und es dann über die API herunterzuladen. Data Explorer-Abfragen mit der Discourse API ausführen
Absolut; wenn Sie Daten benötigen, die von dem abweichen, was bereits im Admin-Panel angeboten wird, ist DE der richtige Weg.
Es gibt auch die Garantie, dass diese Abfragen nach einem Update keine anderen Daten zurückgeben, ABER auch die zugrunde liegenden Strukturen können sich ändern und Sie müssen die Abfrage möglicherweise warten.
In jedem Fall gibt es Kompromisse.
Vielen Dank euch beiden! Ich habe es mit der „Reverse Engineering“-Methode + API-Schlüssel geschafft! Vielen, vielen Dank!
Etwas spät zu diesem Gespräch, aber ich wollte ebenfalls Daten aus einem Discourse-Forum abrufen und hatte keine Lust, einen API-Schlüssel einzurichten. Wenn du (oder jemand anders) eine einfache Wrapper-Lösung zum Abrufen von Beiträgen aus beliebigen Discourse-Foren suchst, kannst du sie hier ansehen: GitHub - elninotech/discourse-reader: A simple Python wrapper for reading data from Discourse forums · GitHub
Veröffentlicht auf PyPi, also einfach mit pip/uv zu installieren. Berücksichtigt automatisch das Rate Limiting und ist mit Pydantic typisiert (was meiner Meinung nach die Entwicklererfahrung verbessert). Verwendung:
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# Kategorien durchsuchen
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} Themen")
# Ein Thema mit allen seinen Beiträgen abrufen
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # Der ursprüngliche Beitrag (HTML)
print(topic.accepted_answer) # Akzeptierte Antwort oder None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
Dies bietet definitiv keine besseren oder schnelleren Daten als das Data Explorer-Plugin, aber ich finde es praktisch, wenn man einfach schnell eine Reihe von Threads oder einfache Statistiken einer Website abrufen möchte 
Ich habe den Eindruck, dass dieser Ansatz gegen die Nutzungsbedingungen dieses Forums und die Standard-Nutzungsbedingungen für Discourse-Foren verstoßen könnte.
Sie dürfen keinen automatisierten Zugriff auf das Forum durchführen oder das Forum überwachen, beispielsweise mit einem Web-Crawler, einem Browser-Plugin oder einer Erweiterung oder einem anderen Computerprogramm, das kein Webbrowser ist. Sie dürfen das Forum durchsuchen, um es für eine öffentlich zugängliche Suchmaschine zu indizieren, sofern Sie eine betreiben.
Hmmm. Ich glaube nicht, dass ich etwas Besonderes tue, als einfach das zu umhüllen, was sonst eine einfache curl-Anfrage an öffentlich dokumentierte API-Endpunkte wäre. Falls das @Discourse-Team jedoch mit dem, was ich erstellt habe, nicht einverstanden ist, lassen Sie es mich bitte wissen.
Persönlich glaube ich nicht, dass das Paket selbst gegen die Nutzungsbedingungen verstößt, da die Verantwortung, die Nutzungsbedingungen eines Forums zu respektieren, immer beim Entwickler liegt, der das Tool verwendet. Dieses Paket greift nur auf öffentliche und dokumentierte API-Endpunkte zu. Wenn ein Entwickler böswillige Absichten hat, ein Forum zu scrapen oder zu überwachen, wäre dies ehrlich gesagt ohnehin eine triviale Aufgabe.
In diesem Zusammenhang bietet pydiscourse die gleiche Funktionalität. Der einzige Unterschied besteht in der Notwendigkeit eines API-Schlüssels (ich weiß nicht, wie einfach dies für einen regulären Benutzer ist), wonach es ebenfalls verwendet werden kann, um die Nutzungsbedingungen eines Forums zu verletzen. Wenn die Standardregel also lautet, dass der automatisierte Zugriff auf das Forum nicht erlaubt ist, würden dann nicht auch pydiscourse und discourse2 gegen die Nutzungsbedingungen verstoßen? discourse2 wirbt sogar in seiner Funktionsliste mit dem Zugriff auf öffentlich zugängliche Daten, falls kein API-Schlüssel bereitgestellt wird:
Funktioniert sowohl in Server- als auch in Browserumgebungen* (*nützlich zum Abfragen öffentlicher Daten ohne API-Schlüssel und mit relevanter Herkunft, z. B. neueste Themen usw.)
Es gibt wahrscheinlich noch viele weitere Pakete in anderen Sprachen, die bereits diesen Art von Zugriff unterstützen.
Ein wenig mehr Kontext: Ich habe dies entwickelt, um Daten von einem Forum leicht abrufen zu können, das einer unserer Kunden hostet (wir haben jedoch keinen direkten Datenbankzugriff). Es macht meinen Arbeitsablauf einfach sauberer, und ich hoffe, anderen zu helfen, die sich in derselben Situation befinden.
Die Sache ist die, dass die Generierung eines API-Schlüssels zunächst Zugriff auf die Admin-Oberfläche erfordert (Admin > Erweitert > API-Schlüssel). Daher wäre die Vergabe eines API-Schlüssels etwas, das die Administratoren möchten; ein normaler Benutzer kann nicht einfach einen erhalten.
Ja, wenn der einzige Weg, einen API-Schlüssel zu erhalten, über die Admin-Oberfläche führt, könnte dieses Paket die Verletzung der Nutzungsbedingungen (ToS) eines bestimmten Forums erleichtern.
Dennoch möchte ich einige der anderen Punkte, die ich angesprochen habe, weiter erörtern und auch die Meinungen anderer dazu hören, nämlich: Jeder könnte bereits trivialerweise mit curl oder requests scrapen oder überwachen. Sollte die Verantwortung nicht bei dem Entwickler liegen, die ToS nicht zu verletzen? Oder sollte sie bei den von ihnen verwendeten Tools selbst liegen?
Bei discourse2 und ähnlichen Paketen sind diese breiter angelegt, aber discourse2 wirbt immer noch mit der Möglichkeit, mit öffentlichen Endpunkten zu arbeiten, wenn kein API-Schlüssel angegeben wird. Ermöglicht das die Verletzung der ToS in gleichem Maße?
Außerdem: Da Discourse unter der GPLv2 steht, verstößt die Erstellung eines Tools wie discourse-reader inhärent direkt gegen irgendwelche Bedingungen?
Ich bin gespannt auf die Meinungen anderer zu diesen Punkten.
Das offizielle Ruby-Gem discourse_api unterstützt auch den Zugriff auf öffentliche Daten ohne API-Schlüssel. Daher ist es meiner Meinung nach in Ordnung, dass es solche Tools gibt. Es liegt jedoch an den Nutzern, sicherzustellen, dass sie die jeweiligen Nutzungsbedingungen (ToS) der Foren einhalten.
(Das ist meine persönliche Meinung – keine offizielle Rechtsaussage von CDCK 
)
Es ist auch erwähnenswert, dass nicht-authentifizierte „Bot“-Anfragen deutlich strengeren Ratenlimits unterliegen und möglicherweise weiteren „Bot-Schutz“-Sicherheitsebenen (z. B. Cloudflare) ausgesetzt sind. Wenn es möglich ist, ist es daher immer am besten, einen API-Schlüssel zu verwenden.
Danke für die Antwort! Derzeit habe ich das README in meinem Paket mit einem Haftungsausschluss aktualisiert, der die Einhaltung der Nutzungsbedingungen (ToS) jeder Website fordert, gegen die ein Entwickler es möglicherweise einsetzen möchte.
Mir war diese Standard-ToS-Regel bei der Erstellung überhaupt nicht bewusst. Hoffentlich erfährt auch jeder, der dieses Paket in Zukunft nutzen möchte, davon
Ja, das spiegelt genau die Argumente wider, die vor einiger Zeit für Videorekorder (VCRs) vorgebracht wurden. Ähnlich ist es bei Schlossbrechern. Es gibt legitime und illegitime Anwendungen von Werkzeugen, und es obliegt dem Bediener, verantwortungsvoll zu handeln.
Noch einmal: Ich bin kein Anwalt und dies ist keine offizielle Stellungnahme, aber ich finde, dies gibt unsere Sichtweise treffend wieder:
Es gibt einen großen Unterschied zwischen gut gemeinter Erkundung mit einem Tool (z. B.) und dem Einrichten von Automatisierung.
Wir werden nicht mürrisch mit Leuten umgehen, die Meta mit solchen Tools nutzen, besonders wenn sie Funktionen entwickeln oder lernen, wie man mit der Discourse-API interagiert. Wir werden dies begrüßen, solange Sie keine Daten im großen Stil abgreifen, keine unnötige Last verursachen oder die Erfahrung anderer beeinträchtigen.