API 사용과 관련된 보안에 대해 질문이 있습니다. 경험이 부족해서 어떤 단순한 개념을 놓치고 있는 것 같거든요.
프론트엔드에 통합할 헤드리스(headless) 방식의 Discourse 구현체를 가지고 있으며, 사용자 인증을 위해 SSO를 성공적으로 활성화했습니다.
처음에는 SSO를 사용하여 "activeUser"로 인증하고, API에서 해당 activeUser에 특화된 데이터를 가져오는 것으로 이해했습니다. 하지만 이제 보니 그게 완전히 정확하지는 않더군요.
이제 반환되는 데이터가 헤더에 전달된 'api-username’에 따라 달라지는 것 같습니다. 저는 Admin API 키를 사용 중이므로, "api-username"에 올바른 사용자명을 전달하면 원하는 사용자의 데이터를 가져올 수 있다고 믿습니다.
따라서 제 질문은 이렇습니다. API에는 "activeUser"라는 개념이 도입되지 않은 것처럼 보이는데, external_id를 통해 사용자명을 검색한 후, 활성 세션 전체에서 이를 api-username으로 사용하여 활성 사용자를 조정해야 한다는 것이 맞나요?
제 이해가 맞다면, 해커가 헤더의 api-username을 쉽게 수정하여 아무 사용자의 채팅 토론을 가져올 수 있는 것 아닌가요?
이해를 돕기 위해 추가 정보가 있다면 감사하겠습니다. 감사합니다!
읽어본 관련 게시물들:
Discourse contains a system for generating API keys per user if a very specific protocol is followed. This feature facilitates “application” access to Discourse instances without needing to involve moderators.
High level description
At a high level:
Client (desktop app, browser plugin, mobile app) generates a private/public key pair and return url
Client redirects to a route on discourse giving discourse its public key
Discourse gets approval from user to use app
Discourse generat…
If you have an existing website or application and you would like to encourage discussion on your Discourse forum it can be helpful to display Discourse notifications inside of your application. This guide will show you how to use the Discourse API to fetch notifications for a user and how to mark them as read.
The recommended way of using the API is to have your application make back-end requests to Discourse and then pass that data to the front-end/presentation layer of your application.
Che…
Hi,
I enabled the setting “Require authentication to read content on this site, disallow anonymous access”.
I’m making a GET request to the /users/by-external/{EXTERNAL_ID}.json endpoint, and without the above setting enabled, it returns a user perfectly fine. But when I enable the above setting, the GET request returns nothing.
For reference, I have SSO enabled.
Let me know if there’s a workaround or if I’m thinking about this incorrectly.
Thanks in advance!
사용자별 API 키를 얻는 방법에 대한 가이드를 따르고 있습니다: User API keys specification .
다음 단계들을 수행했습니다: 클라이언트가 공개/비공개 키 쌍을 생성하고 리턴 URL을 반환한 후, Discourse 경로로 이동하여 사용자가 앱 사용을 Discourse에 승인하고, Discourse가 API 키를 생성합니다.
하지만 Discourse가 리턴 URL의 "payload"로 API 키를 보내올 때, 해당 키가 작동하지 않습니다. 복호화를 시도해 보았지만 실패합니다.
해당 키를 표준 JavaScript 복호화(예: 여기 답변에 있는 것)에 적용해 보면 “length is invalid” 오류가 발생합니다. (사용하는 JavaScript 복호화 방법에 따라 DATA_LEN_NOT_EQUAL_TO_MOD_LEN 오류가 발생하기도 합니다)
이를 해결하는 방법에 대한 아이디어가 있을까요?
이것은 매우 중요한 기능 부분이라 도움이 정말로 절실합니다.
pa…
관리자 API 키는 왕국의 열쇠입니다
프론트엔드 앱 어디에도 이를 노출하지 마세요. 이미 노출했다면 즉시 폐기하는 것을 권장합니다.
michaeld
(Michael - Communiteq)
5월 31, 2024, 4:44오전
3
프론트엔드에서 해당 API를 사용하면 안 됩니다. 그렇게 하면 실제로 위험할 수 있으며(해커가 아무 일이나 할 수 있으므로 위험이 훨씬 더 큽니다)
백엔드에서 이 작업을 수행해야 합니다.
그것이 불가능하다면 사용자 API 키를 사용해야 합니다.
헤드리스(headless) 구현 방식으로 진행할 예정이므로 프론트엔드에서 이를 실행하게 됩니다. 따라서 이 주제에 대한 토론 내용을 파악하는 데 시간을 좀 써야 할 것 같습니다:
Discourse contains a system for generating API keys per user if a very specific protocol is followed. This feature facilitates “application” access to Discourse instances without needing to involve moderators.
High level description
At a high level:
Client (desktop app, browser plugin, mobile app) generates a private/public key pair and return url
Client redirects to a route on discourse giving discourse its public key
Discourse gets approval from user to use app
Discourse generat…
이러한 토론들과 마찬가지로, 관리자 API 접근 권한을 사용하여 사용자의 API 키를 자동 생성하는 것에 관심이 있습니다. 다만 제 플로우에서는 사용자가 새 페이지로 리다이렉트되어 내 앱을 "승인"하는 과정은 원하지 않습니다. 신뢰할 수 있는 관리자 API 키를 사용하여 승인을 강제하거나, 제가 생성하는 새로운 사용자 API 키에 대해 추가 인증이 필요 없도록 비활성화할 수 있는 설정이 있는지 알고 싶습니다.