Grazie mille! Sì, lo farò! Sto cercando specificamente le visualizzazioni di pagina (utenti con accesso effettuato, utenti anonimi, crawler) ma non riesco a trovarle nella documentazione dell’API. Qualche suggerimento?
Alcune chiamate specifiche per l’amministratore non sono presenti nella documentazione dell’API
Apri la scheda di rete, vai alla pagina di amministrazione, visualizza il report con i dati che desideri recuperare e quindi controlla la scheda di rete per vedere cosa ha caricato il browser.
Che è in realtà un riassunto di Reverse engineer the Discourse API
Quello che farei è usare il plugin Data Explorer per ottenere ciò che vuoi e poi puoi scaricarlo con l’API. Esegui query di Data Explorer con l’API di Discourse
Assolutamente; se desideri dati diversi da quelli già disponibili nel pannello di amministrazione, DE è la strada da percorrere.
Inoltre, garantisce che tali query non restituiranno dati diversi dopo un aggiornamento, MA anche che le strutture sottostanti potrebbero cambiare e potrebbe essere necessario mantenere la query.
Compromessi in entrambi i casi.
Grazie a entrambi! Ho risolto con il metodo del “reverse engineer” + chiave API! Grazie mille!
Un po’ in ritardo per questa conversazione (beh, per il suo prolungamento :p), ma volevo anche estrarre dati da un forum Discourse e non volevo la seccatura di configurare una chiave API. Se tu (o chiunque altro) desidera un semplice wrapper per estrarre post da qualsiasi forum Discourse, puoi darci un’occhiata qui
È stato rilasciato su PyPi, quindi è facile da installare con pip/uv, gestisce automaticamente il rate limiting ed è tipizzato con Pydantic (a mio avviso migliora l’esperienza di sviluppo). Ecco come si usa:
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# Sfoglia le categorie
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} argomenti")
# Ottieni un argomento con tutti i suoi post
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # il post originale (HTML)
print(topic.accepted_answer) # risposta accettata o None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
Non è completo come pydiscourse, ma è intenzionale dato che funziona senza una chiave API; inoltre, sicuramente non offrirà dati migliori o più veloci rispetto al plugin Data Explorer, ma penso sia utile se vuoi semplicemente estrarre rapidamente un batch di thread o statistiche di base del sito 
Ho l’impressione che questo approccio possa violare i termini di servizio di questo forum e i termini di servizio predefiniti per i forum Discourse.
Non è consentito automatizzare l’accesso al forum o monitorarlo, ad esempio tramite un web crawler, un plug-in o un componente aggiuntivo del browser, o altri programmi informatici che non siano un browser web. È possibile eseguire il crawling del forum per indicizzarlo in un motore di ricerca pubblico, a condizione che lo gestiate voi stessi.
Hmmm. Non credo di fare nulla di speciale oltre a incapsulare ciò che altrimenti sarebbe una semplice richiesta curl a uno qualsiasi degli endpoint API documentati pubblicamente. Tuttavia, se il team @Discourse si offende per ciò che ho creato, fatemelo sapere.
Personalmente, non credo che il pacchetto stesso violi alcun ToS, poiché la responsabilità di rispettare i termini di un forum spetterà sempre allo sviluppatore che utilizza lo strumento. Questo pacchetto interroga solo endpoint API pubblici e documentati; se uno sviluppatore ha intenzioni malevole di fare scraping o monitorare un forum, questo sarebbe già di per sé un compito banale.
A tal proposito, pydiscourse offre la stessa funzionalità, con l’unica differenza della necessità di una chiave API (non so quanto sia semplice ottenerla come utente regolare), dopo di che può essere utilizzata in modo simile per violare i ToS di qualsiasi forum. Quindi, se la regola predefinita è non automatizzare l’accesso al forum, anche pydiscourse e discourse2 non violerebbero i ToS? discourse2 addirittura pubblicizza l’accesso ai dati pubblicamente accessibili nella sua lista di funzionalità se non viene fornita una chiave API:
Funziona sia in ambienti server che browser* (*utile per interrogare dati pubblici senza chiavi API e su origini rilevanti, ad esempio gli ultimi argomenti, ecc)
Probabilmente esistono molti altri pacchetti in altri linguaggi che già supportano questo tipo di accesso.
Alcuni ulteriori contesti: ho creato questo strumento per poter estrarre facilmente i dati da un forum ospitato da uno dei nostri clienti (ma senza accesso diretto al DB). Mi rende semplicemente il mio flusso di lavoro più pulito e spero di aiutare altri che si trovano nella stessa situazione.
Il punto è che la generazione di una chiave API richiede prima l’accesso all’interfaccia di amministrazione (Amministrazione > Avanzate > Chiavi API), quindi fornire una chiave API è qualcosa che gli amministratori vogliono fare; nessun utente normale può ottenerne una.
Sì, se l’unico modo per ottenere una chiave API è tramite l’interfaccia di amministrazione, allora questo pacchetto potrebbe semplificare la violazione dei Termini di Servizio (ToS) di un forum specifico.
Tuttavia, vorrei ancora discutere alcuni degli altri punti che ho sollevato e conoscere il parere degli altri su di essi, in particolare: chiunque potrebbe già facilmente effettuare scraping o monitoraggio con curl o requests. La responsabilità non dovrebbe ricadere sullo sviluppatore di non violare i ToS? O dovrebbe ricadere sugli strumenti che utilizza?
Per discourse2 e pacchetti simili, hanno uno scopo più ampio, ma discourse2 continua a pubblicizzare la possibilità di funzionare su endpoint pubblici se non viene fornita una chiave API. Questo abilita la violazione dei ToS allo stesso grado?
Inoltre, dato che Discourse è sotto licenza GPLv2, la creazione di uno strumento come discourse-reader viola intrinsecamente direttamente qualche termine?
Sono curioso di conoscere il pensiero degli altri su questi aspetti.
Il gem ruby ufficiale discourse_api supporta anche l’accesso ai dati pubblici senza una chiave API. Quindi, secondo me, va bene che esista questo strumento. Spetta agli utenti assicurarsi di rispettare i Termini di Servizio specifici di ogni forum.
(Questa è la mia opinione personale, non una dichiarazione legale ufficiale da parte di CDCK 
)
Vale anche la pena notare che le richieste di ‘bot’ non autenticate sono soggette a limiti di frequenza molto più rigorosi e, potenzialmente, ad altri livelli di sicurezza per la protezione dai ‘bot’ (ad esempio Cloudflare). Quindi, se possibile, è sempre meglio utilizzare una chiave API.
Grazie per la risposta! Per il momento, ho aggiornato il README nel mio pacchetto con una nota per rispettare i Termini di Servizio del sito che uno sviluppatore potrebbe voler utilizzare. Non ero a conoscenza di questa regola standard dei Termini di Servizio al momento della creazione; spero che chiunque in futuro intenda utilizzare questo pacchetto ne venga a conoscenza anch’esso
Sì, questo riflette esattamente gli argomenti a favore dei videoregistratori… un po’ di tempo fa. Allo stesso modo, le grimaldelle. Esistono usi legittimi e illegittimi degli strumenti e spetta all’operatore essere responsabile.
Ancora una volta, non sono un avvocato e questa non è una dichiarazione ufficiale, ma credo che questo rappresenti accuratamente il nostro punto di vista:
C’è una grande differenza tra l’esplorazione benintenzionata con uno strumento (ad esempio) e l’implementazione di automazione.
Non ci arrabbieremo con le persone che usano Meta con strumenti del genere, specialmente se stanno sviluppando funzionalità o imparando a interagire con l’API di Discourse. Incoraggeremo questa pratica, purché non si proceda al web scraping massivo dei dati, non si generi un carico eccessivo o non si degradi l’esperienza degli altri.