I find allowed_user_api_auth_redirects default of “discourse://auth_redirect” rather restrictive, especially because “discourse” does not appear to be a valid URI scheme.
Please explain the thinking behind this default. Thank you.
I am having this issue as well. If I initiate the API from a JS application, then automatically the allowed headers are: User-Api-Key, User-Api-Client-Id even though I do not need user API keys. All I want is a simple API key but I cannot get anything to work. If I try to pass Api-Key in the headers I get a CORS error since it expects User-Api-Key. But when I try to use User-Api-Key, I get 403 errors. I am stuck. I would think this is the base usage for using the APIs. I am not trying to do anything out of the ordinary. I am simply trying to create a new topic post.
2개의 좋아요
That is the custom URI scheme used by the DiscourseHub app for iOS and Android.
6개의 좋아요
“읽기 토큰”과 “쓰기 토큰”에 대해 질문이 있습니다. 여기 있는 코멘트는 2016년 것이므로 이미 변경되었을 가능성이 있나요? 아니면 기본값이 여전히 “읽기 토큰”만 허용하는 건가요?
배경: 저는 분산형 소셜 미디어 시스템의 개발자 중 한 명입니다. 우리는 이미 연동되지 않는(non-federating) 시스템과의 커넥터를 갖추고 있습니다. 아이디어는 Discourse용 애드온도 작성하는 것입니다. 하지만 대부분의 시스템이 사용자가 게시를 허용하는 토큰을 생성하는 것을 허용하지 않을 가능성이 높으므로, 다른 방법을 시도할 것입니다. 우리는 이미 메일 커넥터를 갖추고 있습니다. 그러면 단순히 Discourse의 메일링 리스트 기능을 사용하고, 반환된 콘텐츠를 강화한 후 SMTP를 통해 게시할 것입니다.
사전적으로 범위를 요청하면 쓰기 토큰을 발급받을 수 있습니다.
3개의 좋아요
물론 항상 가능합니다. 하지만 제 느낌으로는 이것이 지원(고객 지원)의 악몽이 될 것 같습니다. 우리의 소프트웨어에는 약 100개 이상의 설치 환경이 있으며, 총 사용자 수는 10,000명 이상입니다. Discourse와 연결되는 애드온이 있다는 것을 알게 되면, 많은 사람들이 분명히 이를 사용하길 원할 것입니다. 그리고 아마도 바로 작동하지 않을 가능성이 높기 때문에, 우리 쪽에서 질문과 지원 업무가 발생할 것입니다. 또한 여러 Discourse 설치 환경의 관리자들도 업무를 수행해야 할 것입니다. 그리고 아마도 모든 관리자가 이를 허용하지 않을 것이며, 이는 불만을 초래할 것입니다.
따라서 처음에는 메일링 리스트 모드 메일 통합에 집중할 수도 있습니다. 또는 이 두 가지를 결합하는 것이 가능한가요? 즉, 게시글 읽기는 API를 통해, 게시글 작성은 SMTP를 통해 수행하는 방식입니다.
안녕하세요… public_key를 생성하는 방법을 모르겠습니다. RSA 생성기를 사용하여 공개/비공개 키를 가져와야 하나요?
만약 그렇다면 몇 가지 온라인 RSA 생성기를 사용해 보았지만, 다음과 같은 오류가 발생합니다:
OpenSSL::PKey::RSAError (Neither PUB key nor PRIV key: nested asn1 error) /var/www/discourse/app/controllers/user_api_keys_controller.rb:189:in `initialize'
또한 제 사용 사례에 적합한지 여쭤보고 싶습니다:
앱이 있으며, 기본적으로 사용자를 인증하고 사용자 이름을 가져오려고 합니다. 제 앱에서 사용자 로그인을 검증하는 가장 간단한 플로우가 API 키 생성 플로우인가요? 가능하다면 SSO는 더 복잡해 보이므로 피하고 싶습니다.
저도 같은 상황입니다. 다만 저는 User-Api-Key(일반적인 Api-Key가 아님)를 사용하여 토픽 게시글을 작성하려는데, actionpack 라이브러리에서 CSRF 거부를 받고 있습니다.
Discourse 서버에서 CSRF 검사를 끄지 않는 한, 제3자 데스크톱 앱에서 게시글을 작성하는 것은 쉽지 않은 것 같습니다. 브라우저를 에뮬레이션하는 일은 하지 않을 겁니다.
@sam read 스코프만 부여된 사용자 API 키를 GET 요청의 URL 파라미터로 전달하도록 허용하는 것에 대해 어떻게 생각하시나요?
구체적인 사용 사례는, 사용자 API 키를 사용하여 Improved Bookmarks with Reminders와 같은 통합 기능을 통해 Google 캘린더에 구독하는 것을 허용하는 것입니다.
5개의 좋아요
"get param 허용"을 나타내는 세 번째 매개변수를 가진 새로운 특정 스코프를 만드는 것은 어떨까요? 이렇게 하면 다른 용도로 오용하는 것을 방지할 수 있습니다(예: CORS 우회 및 다른 사이트에서 Discourse API 요청).
(여기에서 가져옴)
SCOPES = {
read: [:get],
write: [:get, :post, :patch, :put, :delete],
message_bus: [[:post, 'message_bus']],
push: nil,
one_time_password: nil,
notifications: [[:post, 'message_bus'], [:get, 'notifications#index'], [:put, 'notifications#mark_read']],
session_info: [
[:get, 'session#current'],
[:get, 'users#topic_tracking_state'],
[:get, 'list#unread'],
[:get, 'list#new'],
[:get, 'list#latest']
],
+ calendar: [ [:get, 'users#bookmarks_cal', true ] ],
}
(참고: 여기서 왜 중첩된 배열을 사용하고 있나요…)
10개의 좋아요
API 키가 사용자 수준에서 "GET에서 허용됨"으로 명시적으로 플래그가 지정되는 점이 좋습니다.
전체적으로 이 옵션은 모든 GET 요청에 열려 있을 수 있습니다. 제가 좋아하는 규칙은 이 모드로 작동할 때 다음과 같습니다:
- 사용자 API 키는 특정 단일 GET 컨트롤러 액션으로 100% 제한됩니다.
- 사용자 API 키는 GET 쿼리 매개변수에서 허용되도록 플래그가 지정됩니다.
이로 인해 프록시를 통한 누출의 영향이 제한됩니다. 왜냐하면 키가 다시 사용되지 않기 때문입니다.
{get: 'list#new'} , {get: 'list#latest'} 도 작동할 것 같습니다.
7개의 좋아요
get param only 유형의 사용자 API 키에 대해 매우 관심이 많습니다. 질문이 하나 있는데, UI를 통해 이러한 키를 생성할 수 있도록 할 계획이 있으신가요?
아마도 사이트 설정이나 플러그인을 통해 가능할 것 같습니다. 관리 API 키에도 스코프를 지원하도록 기능 세트를 조금 더 표준화할 계획입니다.
4개의 좋아요
안녕하세요.. 이 문제를 해결할 수 있을까요? 저도 같은 문제를 겪고 있는데 해결이 되지 않습니다. 다양한 유형의 키를 전달해 보았지만 아무것도 작동하지 않았습니다. 도움을 주시면 감사하겠습니다.
이 작업을 위한 라이브러리가 있나요? 없다면, 예제 구현을 보여줄 수 있을까요? 저는 PHP를 사용하여 웹사이트의 다른 부분에서 사용자의 Discourse 계정을 식별하려고 하고 있습니다. 이것은 수정된 OAuth 플로우처럼 보이지만, 어떻게 구현해야 하는지 조금 혼란스럽습니다.
특히 공개/비공개 키 생성을 어떻게 해야 하는지 확실하지 않습니다.
Discourse를 OAuth 제공자로 사용하여 OAuth 2를 그대로 사용할 수 있는 방법이 있을까요?
2개의 좋아요
User-Api-Key를 사용하여 성공하셨나요? 저도 You are not permitted to view the requested resource 오류가 발생합니다.
1개의 좋아요
내가 무엇을 잘못했는지 파악했습니다: 반환된 페이로드가 UserAPI 키 자체는 아니라, 개인/공개 키 쌍의 개인 키로 복호화해야 하는 암호화된 JSON 문자열이었습니다.
2개의 좋아요
수정: 대부분 작동하도록 만들었고, 완전히 작동하게 되면 설명을 제공하겠습니다.
클라이언트는 개인 키/공개 키 쌍과 ID를 어떻게 얻나요?
JavaScript 앱으로 사용자 API 키를 가져오는 코드를 제공해 주실 수 있나요? (JavaScript 앱이 사용자로 하여금 discourse 포럼에 API 호출을 하도록 허용하는 경우).
403 오류가 발생하고 있습니다. 또는, 죄송합니다. 사용자 API 키를 발급할 수 없습니다. 이 기능이 사이트 관리자에 의해 비활성화되었을 수 있습니다라는 오류 메시지가 표시됩니다. (제 사이트에서는 사용자 API 키 생성 허용을 체크해 두었습니다).
문제가 개인 키/공개 키 쌍을 생성하는 방법(그것이 어떻게 이루어지나요?)과 리다이렉트를 처리하는 방식일 수 있다고 생각합니다.
어떤 코드든 감사하겠습니다.
여러 번 시행착오를 거친 끝에 결국 성공했습니다.
다음은 제가 따르는 기본적인 단계입니다. 제가 직접 코딩한 별도의 애플리케이션이 있고, 사용자가 해당 애플리케이션을 통해 Discourse 사이트로 API 호출을 하도록 하고자 할 때 적용하는 방법입니다.
이를 위해서는 각 사용자를 대신하여 호출을 수행하기 위해 사용자별 API 토큰을 생성해야 합니다(적어도 nodejs/javascript 환경에서는 그렇습니다).
참고로 javascript 쪽과 관련하여, @KengoTODA 님이 여기에서 제공한 코드가 매우 유용했습니다: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
제가 따랐던 단계는 다음과 같습니다:
첫째: 공개 키와 비밀 키 쌍을 생성합니다.
이것은 애플리케이션이 생성해야 하는 사항으로, 공개 키와 비밀 키가 필요합니다. GitHub gist에 이를 수행하는 한 가지 방법이 나와 있습니다.
둘째: 리다이렉트 URL을 준비합니다.
이것은 Discourse가 최종 API 토큰을 페이로드에 담아 리다이렉트할 URL입니다. 데스크톱 애플리케이션(즉, 브라우저 URL이 없는 경우)을 사용하는 경우, 리다이렉트 URL은 브라우저에 입력하면 해당 애플리케이션을 여는 데 사용되는 사용자 정의 프로토콜 기반으로 설정됩니다.
참고로 리다이렉트 URL은 대상 Discourse 사이트의 사이트 설정에 화이트리스트로 등록되어야 합니다.
Discourse 사이트에는 또한 "사용자 API 키 허용"이라는 사이트 설정이 체크되어 있어야 할 가능성이 높습니다. 이 주제에 대한 원본 게시물의 “사이트 설정” 부분을 참고하세요.
셋째: Discourse 요청 URL로 API 요청을 보냅니다.
따라서 애플리케이션은 다음과 같은 형식의 URL로 호출을 보내야 합니다:
https://[대상 discourse 사이트 .com]/user-api-key-new"
그리고 다음 매개변수를 추가합니다:
- 애플리케이션 이름
- “client_id” (데스크톱 애플리케이션의 경우, 위에서 언급한 GitHub gist와 마찬가지로
const {hostname} = require('os')의 hostname()을 사용할 수 있었습니다) - 스코프 (API를 통해 사용자가 수행할 수 있도록 하려는 스코프로, “write”, “read” 등)
- 공개 키 (위 1단계에서 생성한 것)
- 리다이렉트 URL (위 2단계에서 설정한 것)
- nonce (임의로 선택할 수 있는 값입니다 — '1’을 사용하는 것만으로도 작동하는 것으로 보입니다)
넷째: 사용자가 요청 URL에 의해 열린 Discourse 사이트 페이지에서 애플리케이션을 승인합니다
요청 URL을 성공적으로 보내면, Discourse 사이트에서 사용자에게 해당 애플리케이션이 사이트에 액세스하려고 한다는 내용을 알려주는 페이지가 열립니다.
해당 페이지에는 이를 허용하도록 하는 버튼이 있습니다. 사용자가 이 버튼을 클릭하면 Discourse 사이트가 제공한 리다이렉트 URL로 리다이렉트되고, ?payload=[API 키]를 매개변수로 첨부합니다. 여기서의 API 키는 애플리케이션에서 디코딩해야 할 키입니다.
다섯째: 애플리케이션이 리다이렉트 URL 값(페이로드 값 포함)을 수신하고 API 키를 디코딩합니다
거의 다 왔습니다. 애플리케이션은 Discourse가 이동한 리다이렉트 URL을 파싱하여 페이로드에 포함된 API 키를 가져와야 합니다.
해당 API 키를 얻으면 두 가지 작업을 수행해야 합니다:
- 실제 키를 가져옵니다. URL 인코딩된 버전이 아닙니다: URL에서 매개변수를 가져오는 경우, 보통 URL 인코딩되어 있습니다(여기저기에 %가 추가되는 등). 이를 정리해야 합니다. javascript의 경우
decodeURIComponent가 이 용도로 작동하는 것으로 확인되었습니다. - Discourse에서 반환된 정리된 API 키를 얻으면, 이를 디코딩해야 합니다. 이를 위해 javascript의 비밀 키 디코딩을 사용할 수 있습니다. 기본적으로 1단계에서 생성한 비밀 키를 사용하여 정리된 API 키를 디코딩합니다. 위에서 언급한 GitHub gist에 해당 예제 javascript가 있습니다: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
디코딩 코드를 실행하면 토큰 자체를 얻게 되며, 이제 이를 사용하여 사용자를 대신하여 인증된 API 호출을 수행할 수 있습니다.
여섯째: 토큰(즉, 최종적으로 정리되고 디코딩된 API 키)을 사용하여 사용자를 대신하여 API 호출을 수행합니다
해당 토큰을 사용하면 API 호출 시 사용자 이름을 입력할 필요가 없는 것으로 보입니다. GET, POST, PUT 등의 호출에 다음 헤더를 포함하는 것으로 충분하다고 생각합니다:
headers: {
"User-Api-Key": [토큰]
}
이로써 hopefully Discourse와 상호작용하기 위한 작동하는 사용자별 인증 방법을 갖추게 됩니다.
7개의 좋아요
allowed_user_api_auth_redirects에 항목을 추가할 때의 보안 영향은 무엇인가요? NextCloud 통합을 지원하기 위해 문자열을 추가해 달라는 요청을 받았습니다.
1개의 좋아요