기존의 Discourse 사용자를 intercoin.app로 가져오는 올바른 방법은 무엇인가요? 해시된 비밀번호와 솔트 등을 포함한 모든 사용자를 반환하는 REST 엔드포인트가 있나요? GitHub에서 해시 알고리즘에 대한 링크는 무엇인가요? 만약 우리의 해시 알고리즘이 작동하지 않는다면, 해당 사용자가 로그인할 수 있도록 입력된 비밀번호와 솔트를 동일한 해시 알고리즘으로 처리하기 위해 우리 측에서 코드를 작성해야 할 것 같습니다. Discourse 사용자가 나중에 SSO를 활성화할 때(우리가 하려는 것처럼) #2번 항목이 관련될 것이라고 생각하므로, 이 문제를 해결하면 다른 Discourse 사용자들에게도 도움이 될 것입니다.
def confirm_password?(password)
return false unless password_hash && salt
self.password_hash == hash_password(password, salt)
end
def hash_password(password, salt)
raise StandardError.new("password is too long") if password.size > User.max_password_length
Pbkdf2.hash_password(password, salt, Rails.configuration.pbkdf2_iterations, Rails.configuration.pbkdf2_algorithm)
end
네! 모든 Discourse 사용자를 순회하여 패스워드 해시를 함께 가져와서 우리 플랫폼에 가져오는 스크립트를 작성할 수 있었습니다.
곧, Discourse 포럼을 사용하는 누구나 이벤트, 화상회의, 미디어 등을 추가할 수 있게 될 것이며, Discourse는 “토론” 탭에 위치하게 됩니다. 결과는 https://intercoin.app 에서 확인하실 수 있습니다.
기본적으로 어떤 Discourse 설치 환경이든 Facebook 스타일의 현대적인 소셜 네트워크로 전환하는 것입니다. 우리는 이러한 기능에 수년간 작업해 왔으며, 이제 Discourse와 Wordpress와도 긴밀하게 통합하기를 원합니다. 그러면 사람들이 Wordpress, Discourse, Qbix를 결합하여 자신의 커뮤니티를 완전히 자체 호스팅할 수 있게 됩니다.
Qbix에서는 서버로 전송하기 전에 클라이언트 측에서 최소한 sha1(password + userId)로 비밀번호를 해시합니다. https를 사용하더라도 마찬가지입니다. 이를 통해 서버나 MITM(상호 인증 중간자 공격)이 비밀번호를 절대 볼 수 없도록 하여 사이트 간 재사용을 방지합니다. 그러나 Discourse는 단순히 비밀번호를 서버로 전송합니다. 그래서 클라이언트 측의 이 해싱을 끄야 했습니다. 클라이언트 측에서 hash_pbkdf2를 몇 번 반복하고 나머지는 서버 측에서 수행하는 것이 가능한가요? 시도해 보았지만 결과가 일치하지 않는 것 같습니다:
우리 사이트를 SSO 제공자로 사용하는 대신, Discourse를 SSO 제공자로 사용하는 것이 가능한가요? 그러면 Discourse 포럼 호스트들이 로그인 방식이 그대로 유지되고 Discourse 측에서 처리되므로 Qbix 기능으로 확장할 가능성이 더 높아질 것입니다. Facebook, Google, 기타 모든 서비스처럼요. Discourse Connect가 SSO 제공자로 기능할 때 소비자 사이트로 반환하는 정보의 종류에 대한 문서가 있나요? 다운로드할 수 있는 사진, 이름, 성, 그리고 적어도 사용자 이름은 포함되나요?
Discourse에는 비밀번호를 전송하기 전에 소금(userId를 사용하면 됩니다)을 사용하여 해시하는 것을 권장합니다. 왜 안 하겠습니까? 현재 데이터베이스에 저장하는 것과 호환되지 않아도 되는 것이 아닙니다. 단순히 첫 100회 반복을 JavaScript에서 수행하고, 64000에서 10을 빼면 됩니다. 어차피 커스텀 구현(rails에서 복사한 것)을 가지고 있으므로 isHashed 변수를 함께 보내고, 이 값이 true라면 “마지막” 64K-10 단계만 수행하면 됩니다.