Muito obrigado! Sim, farei isso! Estou procurando especificamente por visualizações de página (usuários logados, usuários anônimos, rastreadores), mas não consigo encontrar isso na documentação da API. Alguma dica?
Algumas das chamadas específicas de administrador não estão na documentação da API
Eu abriria a aba de rede, iria para a página de administrador, visualizar o relatório com os dados que você deseja recuperar e, em seguida, verificaria a aba de rede para ver o que o navegador carregou.
O que é realmente um resumo de Reverse engineer the Discourse API
O que eu faria é usar o plugin Data Explorer para obter o que você quiser e então você pode baixar isso com a API. Executar consultas do Data Explorer com a API do Discourse
Com certeza; se você deseja dados diferentes daqueles já oferecidos no painel de administração, DE é o caminho a seguir.
Isso também garante que essas consultas não retornarão dados diferentes após uma atualização, MAS as estruturas subjacentes também podem mudar e você pode precisar manter a consulta.
Compromissos de qualquer maneira.
Obrigado a ambos! Eu me safei com o método de “engenharia reversa” + chave de API! Muito obrigado!
Cheguei um pouco tarde a essa conversa (bem, à sua continuação :p), mas eu também queria extrair dados de um fórum Discourse e não queria a complicação de configurar uma chave de API. Se você (ou qualquer pessoa) quiser um wrapper simples para buscar posts de qualquer fórum Discourse, pode conferir aqui.
Lançado no PyPI, então é fácil instalar com pip/uv, lida com rate limiting automaticamente e é tipado com Pydantic (o que, na minha opinião, melhora a experiência do desenvolvedor). Uso:
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# Navegar pelas categorias
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} tópicos")
# Obter um tópico com todos os seus posts
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # o post original (HTML)
print(topic.accepted_answer) # resposta aceita ou None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
Não é tão abrangente quanto o pydiscourse, mas isso é intencional, já que funciona sem uma chave de API. Também certamente não oferecerá dados melhores ou mais rápidos do que o plugin Data Explorer, mas acho que é legal se você só quer extrair rapidamente um lote de threads ou estatísticas simples do site 
Tenho a impressão de que essa abordagem pode violar os termos de serviço deste fórum e os termos de serviço padrão dos fóruns Discourse.
Você não pode automatizar o acesso ao fórum nem monitorá-lo, como com um rastreador da web, um plug-in ou complemento de navegador ou outro programa de computador que não seja um navegador da web. Você pode rastrear o fórum para indexá-lo em um mecanismo de busca publicamente disponível, se você tiver um.
Hmm. Não acho que esteja fazendo nada especial além de simplesmente encapsular o que, de outra forma, seria uma simples requisição curl a qualquer um dos endpoints de API documentados publicamente. No entanto, se a equipe do @Discourse se ofender com o que criei, por favor, me avise.
Pessoalmente, não creio que o próprio pacote viole algum ToS, já que a responsabilidade de respeitar os termos de um fórum sempre recairá sobre o desenvolvedor que usa a ferramenta. Este pacote apenas acessa endpoints de API públicos e documentados; se um desenvolvedor tiver intenção maliciosa de fazer scraping ou monitorar um fórum, isso já seria, honestamente, uma tarefa trivial.
Sobre isso, o pydiscourse oferece a mesma funcionalidade; a única diferença é a necessidade de uma chave de API (não sei o quão fácil é obter isso como um usuário comum), após o que ele também pode ser usado para violar os ToS de qualquer fórum. Então, se a regra padrão for não automatizar o acesso ao fórum, não seria o pydiscourse e o discourse2 também violarem os ToS? O discourse2 até mesmo anuncia o acesso a dados publicamente acessíveis em sua lista de recursos caso nenhuma chave de API seja fornecida:
Funciona tanto em ambientes de servidor quanto de navegador* (*útil para consultar dados públicos sem chaves de API e em origem relevante, por exemplo, tópicos mais recentes, etc)
Provavelmente existem muitos outros pacotes em outras linguagens que já suportam esse tipo de acesso.
Mais um pouco de contexto: criei isso para poder extrair dados facilmente de um fórum hospedado por um de nossos clientes (mas não temos acesso direto ao banco de dados). Isso apenas torna meu fluxo de trabalho mais limpo, e minha esperança é auxiliar outros que estão na mesma situação.
O problema é que gerar uma chave de API primeiro exige acesso à interface de Administração (Admin > Avançado > Chaves de API), então fornecer uma chave de API seria algo que os Administradores querem fazer; nenhum usuário comum pode obter uma.
Sim, se a única maneira de obter uma chave de API for por meio da interface de administração, então este pacote poderia simplificar a violação dos Termos de Serviço de um fórum específico.
Ainda assim, quero discutir alguns dos outros pontos que levantei e ouvir as opiniões de outras pessoas sobre eles, a saber: Qualquer pessoa já poderia facilmente fazer scraping/monitoramento com curl ou requests. A responsabilidade não deveria ser do desenvolvedor para não violar os Termos de Serviço? Ou deveria recair sobre as próprias ferramentas que eles utilizam?
Para o discourse2 e pacotes semelhantes, eles têm um escopo mais amplo, mas o discourse2 ainda anuncia a capacidade de funcionar em endpoints públicos se nenhuma chave de API for fornecida. Isso habilita a violação dos Termos de Serviço no mesmo grau?
Além disso, como o Discourse é licenciado sob a GPLv2, a criação de uma ferramenta como o discourse-reader viola inerentemente algum termo diretamente?
Estou curioso para ouvir as opiniões de outras pessoas sobre isso.
O gem oficial em Ruby discourse_api também permite acessar dados públicos de um fórum sem uma chave de API. Portanto, acredito que é aceitável que essa ferramenta exista. Cabe aos usuários garantir que estejam cumprindo os Termos de Serviço específicos de cada fórum.
(isso é minha opinião pessoal - não uma declaração jurídica oficial da CDCK 
)
Vale ressaltar também que solicitações de ‘bots’ não autenticadas estão sujeitas a limites de taxa muito mais rígidos e, potencialmente, a outras camadas de segurança de proteção contra ‘bots’ (por exemplo, Cloudflare). Portanto, se possível, é sempre melhor usar uma chave de API.
Obrigado pela resposta! Por enquanto, atualizei o README no meu pacote com um aviso para respeitar os Termos de Serviço de qualquer site que um desenvolvedor possa querer usar.
Eu não estava ciente dessa regra padrão dos Termos de Serviço quando criei isso. Espero que qualquer pessoa que queira usar este pacote também aprenda sobre isso no futuro também
Sim, isso ecoa diretamente os argumentos a favor dos gravadores de vídeo (VCRs)… de um tempo atrás. Da mesma forma, abre-fechaduras. Existem usos legítimos e ilegítimos de ferramentas, e cabe ao operador ser responsável.
Novamente, não sou advogado e esta não é uma declaração oficial, mas sinto que isso representa com precisão nossa perspectiva sobre o assunto:
Há uma grande diferença entre explorar com boa intenção usando uma ferramenta (por exemplo) e configurar automação.
Não vamos ficar bravos com pessoas que usam o meta com ferramentas como essa, especialmente se estiverem desenvolvendo funcionalidades ou aprendendo a interagir com a API do Discourse. Vamos incentivar isso, desde que você não esteja fazendo raspagem de dados em massa, causando carga indevida ou prejudicando a experiência dos outros.