¡Muchas gracias! ¡Sí, haré esto! Estoy buscando específicamente las vistas de página (usuarios registrados, usuarios anónimos, rastreadores), pero no puedo encontrarlo en la documentación de la API. ¿Alguna indicación?
Algunas de las llamadas específicas de administrador no están en la documentación de la API.
Abriría la pestaña de red, iría a la página de administrador, vería el informe con los datos que desea recuperar y luego revisaría la pestaña de red para ver qué cargó el navegador.
Lo cual es realmente un resumen de Reverse engineer the Discourse API
Lo que yo haría es usar el complemento Data Explorer para obtener lo que quieras y luego puedes descargarlo con la API. Ejecutar consultas de Data Explorer con la API de Discourse
Absolutamente; si desea datos diferentes a los que ya se ofrecen en el panel de administración, DE es el camino a seguir.
También da la garantía de que esas consultas no devolverán datos diferentes después de una actualización, PERO también las estructuras subyacentes pueden cambiar y es posible que deba mantener la consulta.
Compromisos en cualquier caso.
¡Muchas gracias a ambos! ¡Me las arreglé con el método de “ingeniería inversa” + clave de API! ¡Muchísimas gracias!
Un poco tarde para esta conversación (bueno, para su continuación :p), pero también quería extraer datos de un foro de Discourse y no quería el problema de configurar una clave de API. Si tú (o alguien más) quiere un envoltorio sencillo para obtener publicaciones de cualquier foro de Discourse, puedes echarle un vistazo aquí.
Liberado en PyPi, por lo que es fácil de instalar con pip/uv, maneja la limitación de velocidad por ti y está tipado con Pydantic (lo que mejora la experiencia de desarrollo, en mi opinión). Uso:
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# Navegar por categorías
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} temas")
# Obtener un tema con todas sus publicaciones
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # la publicación original (HTML)
print(topic.accepted_answer) # respuesta aceptada o None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
No es tan extenso como pydiscourse, pero eso es intencional ya que funciona sin una clave de API. Tampoco ofrecerá datos mejores o más rápidos que el complemento Data Explorer, pero creo que es útil si solo quieres extraer rápidamente un lote de hilos o estadísticas simples del sitio 
Tengo la impresión de que este enfoque podría violar los términos de servicio de este foro y los términos de servicio predeterminados de los foros de Discourse.
No puedes automatizar el acceso al foro ni monitorearlo, por ejemplo, mediante un rastreador web, un complemento o extensión del navegador, u otro programa informático que no sea un navegador web. Puedes rastrear el foro para indexarlo en un motor de búsqueda de acceso público, siempre que tú lo operes.
Hmmm. No creo que esté haciendo nada especial más que simplemente envolver lo que de otro modo sería una solicitud curl sencilla a cualquiera de los puntos de la API documentados públicamente. Sin embargo, si al equipo de @Discourse le ofende algo de lo que he creado, por favor házmelo saber.
Personalmente, no creo que el paquete en sí viole ningún ToS, ya que la responsabilidad de respetar los términos de un foro siempre recaerá en el desarrollador que utilice la herramienta. Este paquete solo accede a puntos de la API públicos y documentados; si un desarrollador tiene intenciones maliciosas de extraer datos o monitorear un foro, esto ya sería, honestamente, una tarea trivial.
Dicho esto, pydiscourse ofrece la misma funcionalidad; la única diferencia es la necesidad de una clave de API (no sé qué tan fácil sea obtenerla como usuario regular), tras lo cual también podría usarse para violar los ToS de cualquier foro. Entonces, si la regla predeterminada es no automatizar el acceso al foro, ¿no violarían los ToS también pydiscourse y discourse2? discourse2 incluso anuncia el acceso a datos de acceso público en su lista de características si no se proporciona una clave de API:
Funciona tanto en entornos de servidor como de navegador* (*útil para consultar datos públicos sin claves de API y en el origen relevante, por ejemplo, los últimos temas, etc)
Probablemente existan muchos más paquetes en otros lenguajes que ya admitan este tipo de acceso.
Un poco más de contexto: construí esto para poder extraer fácilmente datos de un foro que uno de nuestros clientes aloja (pero no tenemos acceso directo a la base de datos). Simplemente hace que mi flujo de trabajo sea más limpio y mi esperanza es ayudar a otros que se encuentran en la misma situación.
El caso es que generar una clave de API primero requiere acceso a la interfaz de Administración (Admin > Avanzado > Claves de API), por lo que otorgar una clave de API sería algo que los administradores querrían hacer; ningún usuario normal puede obtener una por sí mismo.
Sí, si la única forma de obtener una clave de API es a través de la interfaz de administración, entonces este paquete podría simplificar la violación de los Términos de Servicio (ToS) de un foro específico.
Aunque todavía quiero discutir algunos de los otros puntos que planteé y escuchar las opiniones de otras personas sobre ellos, a saber: Cualquiera ya podría extraer datos o monitorear trivialmente con curl o requests. ¿No debería recaer la responsabilidad en ese desarrollador de no violar los ToS? ¿O debería recaer en las herramientas que utilizan?
Para discourse2 y paquetes similares, tienen un propósito más amplio, pero discourse2 aún anuncia la capacidad de funcionar en puntos de conexión públicos si no se proporciona una clave de API. ¿Eso habilita la violación de los ToS en el mismo grado?
Además, dado que Discourse es GPLv2, ¿la creación de una herramienta como discourse-reader viola inherentemente algún término directamente?
Curioso por escuchar las opiniones de otras personas sobre esto.
El gem de Ruby oficial discourse_api también permite acceder a datos públicos sin necesidad de una clave de API. Por lo tanto, considero que está bien que existan estas herramientas. Corresponde a los usuarios asegurarse de cumplir con los Términos de Servicio específicos de cada foro.
(Esta es mi opinión personal, no una declaración legal oficial de CDCK 
)
También cabe mencionar que las solicitudes de ‘bots’ no autenticadas están sujetas a límites de tasa mucho más estrictos y, potencialmente, a otras capas de seguridad de protección contra ‘bots’ (por ejemplo, Cloudflare). Por lo tanto, si es posible, siempre es mejor utilizar una clave de API.
¡Gracias por la respuesta! Por el momento, actualicé el README en mi paquete con un descargo de responsabilidad para respetar los Términos de Servicio de cualquier sitio que un desarrollador pueda querer utilizarlo contra.
No tenía conocimiento de esta regla predeterminada de los Términos de Servicio en absoluto cuando lo hice; espero que cualquier persona que busque usar este paquete también se entere de ello en el futuro
Sí, esto refleja directamente los argumentos a favor de los reproductores de video… hace un tiempo. De manera similar, los ganzúas. Existen usos legítimos e ilegítimos de las herramientas y depende del operador ser responsable.
De nuevo, no soy abogado y esto no es una declaración oficial, pero creo que esto representa con precisión nuestra perspectiva al respecto:
Hay una gran diferencia entre la exploración bien intencionada con una herramienta (por ejemplo) y configurar la automatización.
No nos pondremos de mal humor con las personas que usan meta con herramientas como esta, especialmente si están desarrollando funcionalidad o aprendiendo a interactuar con la API de Discourse. Lo fomentaremos, siempre que no estén raspando datos masivamente, generando una carga indebida o degradando la experiencia de otros.