이 설정이 하는 일이 이것뿐인가요?
WP에서 이 설정의 이름과 설명이 다소 모호하게 느껴져서, 다른 기능이 더 있는 건 아닌지 궁금해서 여쭤봅니다.
이와 관련하여,
만약 사용자가 이미 WordPress와 Discourse 양쪽에 존재한다면, 어떻게 하면 두 프로필을 병합하거나 연결할 수 있을까요?
기술적으로 말하자면, 이 설정은 사용자가 WordPress에 로그인한 직후 Discourse의 sync_sso 라우트에 호출을 보내고, 그들의 데이터(WordPress user_id, username, name, email…)를 Discourse로 전달합니다. sync_sso 라우트에 대한 자세한 내용은 여기에 있습니다: Sync DiscourseConnect user data with the sync_sso route.
WordPress 사용자들이 Discourse 사이트를 방문한 적이 없는 경우, 이 설정의 유일한 부작용으로 제가 알고 있는 것은 Discourse에서 다이제스트 이메일을 받기 시작한다는 것입니다.
이것이 바로 Discourse 사용자에게 WordPress에 Discourse에서 사용 중인 이메일 주소와 동일한 이메일로 가입하도록 권장해야 하는 이유입니다. 이메일 주소가 일치하는 한, 그들은 올바른 Discourse 계정으로 로그인됩니다. 이는 이전 게시물에서 논의했던 이메일 인증 문제를 처리한다는 전제 하에 해당합니다.
WordPress에 가입할 때 Discourse에서 사용했던 이메일 주소와 다른 이메일을 사용하는 사용자가 있을 가능성이 높습니다. 그런 경우, WordPress 이메일 주소를 사용하여 새로운 Discourse 계정이 생성됩니다. 기존 Discourse 계정을 새로운 Discourse 계정으로 수동으로 병합해야 합니다: Merging user accounts.
만약 WordPress에서 사용자의 이메일을 수동으로 업데이트해야 하는 경우, 이 설정이 활성화되어 있으면 해당 사용자의 Discourse 이메일도 함께 업데이트되나요?
WordPress 프로필 페이지에서 사용자를 업데이트해도 sync_sso 호출이 트리거되지 않습니다. 원래는 그렇게 되어야 할 것 같습니다. 당분간은 사용자에게 WordPress에서 로그아웃한 후 다시 로그인하도록 요청해야 합니다. 관리자가 프로필 페이지에서 WordPress 사용자를 로그아웃시키는 것은 불가능하다고 생각합니다.
WordPress와 Discourse 간에 이메일 및/또는 사용자 이름이 동기화되도록 유지하려면 다음 Discourse 설정을 활성화하십시오:
auth overrides emailauth overrides username
Simon, 감사합니다. 모든 것을 고려한 후, 저는 다음과 같은 과정을 따르겠습니다:
- Discourse에서 사용자 내보내기
- Discourse Connect 활성화
- Wordpress에서 해당 사용자를 가져와 생성하고, WP에서 이메일을 인증된 상태로 표시
- 해당 사용자가 로그인할 때(커스텀 로그인 페이지를 통해) 비밀번호를 재설정해야 합니다.
- 이메일을 입력한 후(시스템이 해당 사용자가 이 세그먼트에 속하는 것을 인식하면) 이 사용자 세그먼트에만 비밀번호 변경을 강제하는 방법
- 또는 로그인 페이지에 메시지를 표시: “[날짜] 이후에 로그인하는 경우 비밀번호를 재설정해야 합니다”
- 접근이 정상적으로 작동해야 합니다!
새로 가입하는 사용자의 경우, 이메일을 인증하는 방법을 찾아야 합니다. 아마도 단순히 비밀번호를 이메일로 전송할 것 같습니다.
또한 Wordpress 프로필에서 “이메일 주소 인증됨” 설정이 선택되지 않았더라도, 사용자가 Discourse에 SSO로 로그인할 수 있다는 것을 발견했습니다. 다만, Discourse에 처음 진입할 때 이메일을 확인해야 합니다. 이는 좋은 점입니다.
이 설정들에 어떤 부작용이 있을까요?
네, 의도된 동작 방식입니다. 대부분의 사용자에게는 큰 장벽이 되지 않습니다. 주의해야 할 점은 WordPress에서 이메일 주소가 확인된 것으로 표시되지 않으면, 사용자가 DiscourseConnect를 통해 Discourse에 처음 로그인할 때 이메일 주소 기준으로 WordPress 사용자와 Discourse 사용자를 매칭하지 않는다는 것입니다. 가져온 사용자의 이메일 주소를 확인된 상태로 표시하는 방법을 찾아낸다면 문제가 되지 않습니다. 확인된 상태로 표시하지 않으면 상황을 정리하는 데 상당한 수고가 들 것입니다.
활성화하면 사용자가 Discourse에서 사용자 이름이나 이메일 주소를 변경하는 것을 방지합니다.
네, 테스트를 많이 해보면서 이 사실을 깨달았습니다. 가져온 모든 사용자를 확인된 상태로 표시하는 커스텀 스크립트를 작성할 예정입니다.
확인해 주셔서 감사합니다!
상세한 /logs를 계속 켜 두는 것이 괜찮을까요?
이렇게 하면 성능에 부정적인 영향을 미칠까요?
verbose 로그를 영원히 켜둔 채로 두는 사례를 본 적이 있습니다. 성능에 의미 있는 영향을 미친다고 생각하지 않습니다. 다만 DiscourseConnect와 무관한 문제를 디버깅하는 경우 로그가 지저분해집니다.
기대한 동작입니다. “로그인 페이지 경로(Path to your Login Page)” 옵션은 기본 WordPress 로그인 경로를 덮어 쓰기 위해 사용됩니다. 이를 위해 WordPress의 login_url 필터에 연결됩니다.
기본 로그인 경로인 /wp-login.php는 제거하지 않으므로, 브라우저 주소창에 해당 URL을 직접 입력하면 여전히 접근할 수 있습니다. /wp-admin으로 이동하는 대신, 기본 로그인 페이지를 사용하려면 /wp-login.php로 이동하세요.
플러그인을 업데이트하여 Discourse 로그인 시에만 "로그인 페이지 경로"로 리다이렉트하도록 하는 방법을 생각할 수 있지만, 그 변경 사항은 상당한 작업이 필요합니다.
걱정 마세요. 그냥 사소한 문제일 뿐이에요. 통찰력 있는 조언 감사합니다!
Hey @simon, 로그에서 다음과 같은 오류가 발생하고 있는데, 이 오류가 무엇을 의미하는지 그리고 어떻게 해결해야 하는지 궁금합니다. 사용자가 로그인 시도를 할 때 오류가 발생한다고 알려주었거든요.
-
(google_oauth2) 인증 실패! csrf_detected: OmniAuth::Strategies::OAuth2::CallbackError, csrf_detected | CSRF 감지됨
-
인증 실패! request_error: OAuth::Unauthorized, 401 Unauthorized
-
(facebook) 인증 실패! no_authorization_code: OmniAuth::Strategies::Facebook::NoAuthorizationCodeError,
code(URL 또는fbsr_XXX서명 요청 쿠키를 통해)를 전달해야 합니다
참고로 이러한 오류는 흔하지 않습니다. 대부분의 로그는 정상적으로 작동하는 것으로 보입니다:
사용자로부터 이 스크린샷을 받았습니다:
그는 "이메일이 없습니다. 가입 링크를 클릭하는 즉시 다음과 같은 페이지가 나타납니다…"라고 말했습니다.
저는 (시크릿 모드에서) 로그인/가입 링크를 클릭해 봤는데 제 환경에서는 정상적으로 작동합니다.
참고로 우리 포럼의 URL은 이렇습니다: forum.projectvanlife.com
"Verbose SSO log"로 시작하는 항목들은 성공적인 로그인 과정을 나타내는 것으로 추정합니다.
“google_oauth2”, “OAuth::Unauthorized”, “facebook” 오류의 경우 무슨 일이 일어나고 있는지 명확하지 않습니다. 이전에 Discourse 사이트가 Google과 Facebook을 통한 사용자 로그인을 허용하도록 설정되어 있었나요? 그렇다면 DiscourseConnect가 활성화된 현재, 해당 방법으로 사이트에 로그인할 수 없습니다. Discourse 설정 페이지에서 Google과 Facebook 로그인을 비활성화해 보시는 것을 권장합니다.
로그인 시 오류가 보고되는 사용자의 경우, 해당 사용자의 로그인 시도와 연관된 verbose SSO 로그 오류 메시지를 찾아보세요. 그런 다음, 이 주제에서 설명된 문제 중 오류가 일치하는 것이 있는지 확인하십시오: Debug and fixing common DiscourseConnect issues.
브라우저 주소 표시줄에 표시된 URL은 https://projectvanlife.com/login/forum/javascript%3Avoid(0입니다.
일부 JavaScript가 잘린 것으로 보이며, 실제로는 javascript:void(0)으로 디코딩되도록 의도된 것 같습니다. 이것이 어디서 오는지 정확히 알 수 없습니다. 아마도 사용자의 브라우저 확장 프로그램 중 하나에서 오는 것일 수 있습니다. 브라우저 확장 프로그램을 비활성화하거나, 시크릿(인코그니토) 창에서 로그인해 보라고 요청해 보세요.
수정: @Sami_Syed 로그인 페이지의 “Sign Up” 링크를 클릭할 때 javascript:void(0) 코드가 경로에 추가되고 있습니다. 해당 링크의 href 요소는: "javascript%3Avoid(0)"입니다.
이것이 사용되는 목적은 가입 양식이 로그인 양식과 동일한 경로에 있도록 하는 것이라고 추측됩니다. 하지만 뭔가 잘못되고 있습니다. DiscourseConnect가 활성화되기 전에 이것이 정상적으로 작동했는지 아시나요?
로그인/가입 양식에 사용되는 플러그인에 가입 양식이 별도의 페이지에 표시되도록 하는 옵션이 있다면, 이를 활성화하는 것이 이 문제에 대한 빠른 해결책이 될 것입니다.
오늘 대부분 오프라인 상태이지만, 막히면 나중에 도움을 드릴 수 있습니다.
수정: 이 부분에 대해 의아해서 다시 확인해 보았습니다. 로그인 양식의 “Register” 탭은 문제없이 작동합니다. “Sign up” 링크에는 위에서 설명한 문제가 있습니다:
따라서 이 문제에 대한 빠른 해결책은 가입 링크를 제거하는 것입니다.
맞습니다.
네, 해당 기능이 활성화되어 있었습니다. 다만 문제는 이제 FB 또는 Google을 통해 로그인을 어떻게 트리거할 수 있느냐는 것입니다. 현재 로그인 페이지에는 그런 기능이 없습니다.
아니면, 원래 G나 FB로 가입한 사람들이 이제 로그인을 시도하지만 작동하지 않아서 이 오류가 발생하는 건가요?
그렇다면 어떻게 해결할 수 있을까요?
확인해 보니, 거기에 올바른 링크를 설정하지 않아서였네요. 오프스. 좋은 지적 감사드립니다!
무엇이 이를 트리거하는지 정확히 모르겠습니다. 아마도 사용자의 브라우저가 인증 제공자(auth provider)의 URL을 캐싱한 것일 수도 있겠네요. 다만 추측일 뿐입니다.