정말 감사합니다! 네, 그렇게 하겠습니다! 구체적으로 페이지뷰(로그인된 사용자, 익명 사용자, 크롤러)를 찾고 싶은데, API 문서에서 찾을 수가 없어요. 혹시 방향이나 힌트를 주실 수 있을까요?
일부 관리자 전용 호출은 API 문서에 포함되어 있지 않습니다.
네트워크 탭을 열고, 관리자 페이지로 이동한 다음, 가져오려는 데이터가 포함된 보고서를 확인한 후, 브라우저가 로드한 내용을 네트워크 탭에서 확인하면 됩니다.
이는 Reverse engineer the Discourse API 에 대한 요약입니다.
제가 할 일은 데이터 탐색기 플러그인을 사용하여 원하는 데이터를 가져온 후, API를 통해 해당 데이터를 다운로드하는 것입니다. Discourse API를 사용하여 Data Explorer 쿼리 실행
물론입니다. 관리자 패널에서 이미 제공되는 것과 다른 데이터를 원하신다면 DE가 정답입니다.
이 방식은 업데이트 후에도 해당 쿼리가 다른 데이터를 반환하지 않는다는 보장을 제공하지만, 동시에 내부 구조가 변경될 수 있으므로 쿼리를 유지보수해야 할 수도 있습니다.
어떤 방식을 선택하든 장단점이 있습니다.
두 분 모두 감사합니다! “리버스 엔지니어링” 방법 + API 키로 성공적으로 해결했습니다! 정말 감사합니다!
이 대화에 좀 늦게 참여하는 것 같네요 (아, 확장된 버전이긴 하지만 :p). 저도 Discourse 포럼에서 데이터를 가져오고 싶었는데, API 키를 설정하는 번거로움을 피하고 싶었어요. 만약 (혹은 누군가) 모든 Discourse 포럼에서 게시물을 가져올 수 있는 간단한 래퍼가 필요하시다면 여기에서 확인해 보실 수 있습니다.
PyPi에 공개되어 있어 pip/uv로 쉽게 설치할 수 있고, 레이트 리미팅도 자동으로 처리해 주며 Pydantic으로 타입이 지정되어 있습니다(개인적으로 개발 경험(DX)이 더 좋다고 생각해요). 사용법:
from discourse_reader import DiscourseClient
client = DiscourseClient("https://meta.discourse.org")
# 카테고리 탐색
for cat in client.categories():
print(f"{cat.name}: {cat.topic_count} topics")
# 모든 게시물이 포함된 토픽 가져오기
topic = client.topics.get(12345)
print(topic.title)
print(topic.opening_post.cooked) # 원본 게시물 (HTML)
print(topic.accepted_answer) # 채택된 답변 또는 None
for reply in topic.posts.replies():
print(reply.username, reply.cooked)
pydiscourse만큼 방대하지는 않지만, 이는 의도적인 것입니다. API 키 없이 작동하기 때문이죠. 또한 data explorer 플러그인보다 더 나은 데이터나 더 빠른 데이터를 제공하지는 않겠지만, 단순히 여러 스레드나 간단한 사이트 통계를 빠르게 가져오고 싶을 때는 꽤 유용하다고 생각합니다 
이 접근 방식이 이 포럼의 서비스 약관 및 Discourse 포럼의 기본 서비스 약관을 위반할 수 있다는 인상을 받습니다.
포럼에 대한 접근을 자동화하거나 웹 크롤러, 브라우저 플러그인 또는 애드온, 웹 브라우저가 아닌 기타 컴퓨터 프로그램 등을 사용하여 포럼을 모니터링할 수 없습니다. 공개적으로 이용 가능한 검색 엔진을 운영하는 경우, 해당 포럼을 색인화하기 위해 포럼을 크롤링할 수 있습니다.
음. 제가 특별히 하는 일은, 공개적으로 문서화된 API 엔드포인트 중 하나에 대한 단순한 curl 요청을 감싸는 것 이상의 것은 아닌 것 같습니다. 다만, @Discourse 팀이 제가 만든 것에 대해 불쾌감을 느낀다면 알려주세요.
개인적으로는, 포럼의 약관을 준수할 책임은 항상 해당 도구를 사용하는 개발자에게 있기 때문에, 이 패키지 자체가 약관(ToS)을 위반한다고 생각하지 않습니다. 이 패키지는 공개되고 문서화된 API 엔드포인트에만 접근하며, 개발자가 포럼을 스크래핑하거나 모니터링할 악의적인 의도가 있다면, 솔직히 말해 이미 자명한 작업이 될 것입니다.
이와 관련하여, pydiscourse도 동일한 기능을 제공하며, 유일한 차이는 API 키가 필요하다는 점입니다(일반 사용자가 이를 얼마나 쉽게 얻을 수지는 모르겠지만), 그 이후에는 마찬가지로 어떤 포럼의 약관을 위반하는 데 사용될 수 있습니다. 따라서 기본 규칙이 포럼에 대한 자동화된 접근을 금지하는 것이라면, pydiscourse와 discourse2도 약관을 위반하는 것 아닌가요? discourse2는 API 키가 제공되지 않을 경우에도 공개적으로 접근 가능한 데이터에 대한 접근을 기능 목록에 명시하고 있습니다:
서버와 브라우저* 환경 모두에서 작동합니다(*API 키 없이 공개 데이터를 쿼리하고 관련 오리진에서, 예: 최신 주제 등, 유용합니다)
이러한 유형의 접근을 지원하는 다른 언어의 패키지들도 아마 많이 있을 것입니다.
추가적인 맥락으로, 저는 우리 고객이 호스팅하는 포럼에서 데이터를 쉽게 가져오기 위해 이 도구를 만들었습니다(우리는 직접 DB 접근 권한이 없습니다). 이는 제 워크플로우를 더 깔끔하게 만들어 줄 뿐이며, 같은 상황에 있는 다른 사람들에게도 도움이 되기를 바랍니다.
사실 API 키를 생성하려면 먼저 관리자 인터페이스(Admin > Advanced > API keys)에 접근해야 하므로, API 키를 발급하는 것은 관리자(Admins)가 원하는 행위입니다. 일반 사용자가 아무나 키를 받을 수 있는 것이 아닙니다.
네, API 키를 관리자 인터페이스에서만 발급받을 수 있다면, 이 패키지는 특정 포럼의 ToS(이용약관) 위반을 용이하게 할 수 있습니다.
다만, 제가 앞서 언급한 다른 몇 가지 사항에 대해 여전히 논의하고 싶고, 특히 다른 분들의 의견을 듣고 싶습니다. 핵심은 다음과 같습니다: 누구나 이미 curl이나 requests로 쉽게 스크래핑/모니터링을 수행할 수 있습니다. 그렇다면 ToS를 위반하지 않을 책임은 해당 개발자에게 있는 것 shouldn’t 인가요? 아니면 그들이 사용한 도구 자체에 있어야 하는 건가요?
discourse2와 유사한 패키지들은 보다 폭넓은 목적으로 사용되지만, discourse2는 API 키가 제공되지 않는 경우에도 공개된 엔드포인트에서 작동할 수 있음을 명시하고 있습니다. 이 경우에도 ToS 위반을 동일하게 용이하게 하는 것인가요?
또한, Discourse가 GPLv2 라이선스를 사용하고 있으므로, discourse-reader와 같은 도구를 만드는 것 자체가 어떤 조항을 직접적으로 위반하는 건가요?
이러한 사항들에 대해 다른 분들의 생각을 듣고 싶습니다.
공식 discourse_api Ruby 지참금(gem)도 API 키 없이 공개 데이터에 접근하는 것을 지원합니다. 따라서 이 도구가 존재하는 것은 문제없다고 생각합니다. 포럼별 서비스 약관(ToS)을 준수하는 것은 사용자의 책임입니다.
(이것은 제 개인적인 의견이며, CDCK의 공식적인 법적 성명이 아닙니다 
)
또한 참고할 점은, 인증되지 않은 ‘봇’ 요청은 훨씬 더 엄격한 속도 제한(rate limits)을 적용받으며, 잠재적으로 다른 ‘봇 방지’ 보안 레이어(예: Cloudflare)의 대상이 될 수 있다는 것입니다. 따라서 가능할 경우 항상 API 키를 사용하는 것이 가장 좋습니다.
답변해 주셔서 감사합니다! 당분간은 제 패키지의 README에 개발자가 이 패키지를 특정 사이트에서 사용하고자 할 경우 해당 사이트의 서비스 약관(ToS)을 준수해야 한다는 면책 조항을 추가했습니다.
이 패키지를 만들 당시 이 기본 ToS 규칙에 대해 전혀 알지 못했습니다. 이 패키지를 사용하려는 모든 분들이 앞으로 이 점에 대해 알게 되기를 바랍니다
네, 이것은 예전에 VCR(비디오 카세트 레코더)에 대한 논쟁과 거의 똑같습니다. 자물쇠 열쇠(lockpick)도 마찬가지입니다. 도구에는 합법적 사용과 불법적 사용이 모두 존재하며, 이에 대한 책임은 운영자에게 있습니다.
다시 한번 말씀드리지만, 저는 법률 전문가(IANAL)가 아니며 이것은 공식적인 성명이 아닙니다. 하지만 저는 이것이 우리의 입장을 정확히 반영한다고 생각합니다:
도구를 이용한 선의의 탐색(예: e.g.)과 *자동화(automation)*를 설정하는 것 사이에는 큰 차이가 있습니다.
이러한 도구를 사용하여 메타 포럼을 이용하는 사용자에게 화를 내지 않을 것입니다. 특히 기능 개발이나 Discourse API 상호작용 방법을 배우기 위해 사용하는 경우라면 더욱 그렇습니다. 대량 데이터 스크래핑, 과도한 부하 발생, 또는 다른 사용자의 경험 저해가 되지 않는 한 우리는 이를 장려할 것입니다.