# 이메일이 고유하지 않은 사용자 인증 시스템에 통합하는 방법?
**URL:** https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489
**Category:** SSO
**Tags:** email
**Created:** [5월 2, 2024, 3:50오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489 "2024-05-02T15:50:43Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [5월 3, 2024, 4:32오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/21 "2024-05-03T16:32:43Z")
저도 바로 그 생각을 하고 있었습니다.
처음에는 검색으로 찾기가 어려워, 해당 주제에 대한 링크를 포함할게요: [Category Group Review/Moderation](https://meta.discourse.org/t/category-group-review-moderation/116478/1)
#announcements 카테고리에서 #documentation을 찾는 데 항상 애를 먹습니다
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [5월 3, 2024, 4:37오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/22 "2024-05-03T16:37:55Z")
> [@jonbarrow](#):
>
> 우리는 이를 개발자 5명으로 제한할 수 있습니다. 이렇게 하면 해당 한도 내에서 운영할 수 있지만, 포럼에서 전체 권한을 부여할 개발자와 부여하지 않을 개발자를 결정해야 합니다.
솔직히, 이는 어쨌든 좋은 아이디어라고 생각합니다. 관리자는 모든 권한(백업 다운로드, 설정 시크릿 확인/변경, 사용자 PII 확인, 개인 메시지 접근 등)을 가지고 있으므로, 이 범위를 좁게 유지하는 것이 가장 좋습니다.
관리자가 아니더라도 "높은 권한"을 가질 수 있는 공간이 많이 있습니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 3, 2024, 4:42오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/23 "2024-05-03T16:42:52Z")
> [@Firepup650](#):
>
> TL4/카테고리 모더레이터들이 여기서 상당한 도움을 줄 수 있을 것 같습니다.
> [@Moin](#):
>
> 저도 정확히 그런 생각이었습니다.
> 처음에는 검색으로 찾기 어려웠기 때문에 [카테고리 그룹 검토/모더레이션](https://meta.discourse.org/t/category-group-review-moderation/116478/1) 토픽 링크를 포함할게요.
> 항상 #announcements::category 카테고리에서 #documentation::category를 찾는 데 어려움을 겪습니다
두 분 모두 감사합니다. 이게 별개의 기능인 줄 몰랐습니다!
> [@supermathie](#):
>
> 솔직히, 어쨌든 좋은 아이디어인 것 같습니다. 관리자(Admins)는 모든 권한(백업 다운로드, 설정 시크릿 확인/변경, 사용자 PII 확인, 개인 메시지 접근 등)을 가지고 있으므로 이 범위를 좁게 유지하는 것이 가장 좋습니다.
>
> 완전한 관리자 권한 없이도 "높은 권한"을 가질 수 있는 여지가 많습니다.
해설해 주셔서 감사합니다. 상황이 그렇다는 것을 몰랐습니다. 말씀하신 대로, 이제 알고 있으니 확실히 제한을 두겠습니다.
> [@supermathie](#):
>
> 관심 있으시다면, 일부 FOSS 프로젝트에 대해 [무료 호스팅](https://free.discourse.group/)을 제공합니다… 여러분의 스태프 수는 저희 제한을 초과하지만, 결정을 내리는 사람들_이_ 그걸 봐줄지 모르겠습니다.
이 호스팅의 제한/요건을 살펴보고 제 팀에 전달했습니다. 불행히도 여전히 셀프 호스팅을 해야 할 것 같습니다. 여러분이 제공하는 FOSS 호스팅은 매우 관대하지만, 단순히 요건에 부합하지 않습니다.
가장 큰 문제는 페이지 뷰 제한입니다. 5만 페이지 뷰/월은 대부분의 FOSS 프로젝트에 충분한 수준일 수 있지만, 우리는 그보다 훨씬 더 많은 트래픽을 생성합니다. 지난 7일 동안만 메인 웹사이트에서 56,470명의 고유 방문자로부터 총 187만 건의 요청을 받았습니다. 이 속도로라면 페이지 뷰 제한을 쉽게 초과할 것 같습니다.
하지만 이것을 알려주셔서 감사합니다!
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5월 3, 2024, 6:19오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/24 "2024-05-03T18:19:40Z")
> [@jonbarrow](#):
>
> 불행히도 스태프가 고유한 이메일 주소를 가지는 것도 보장되지 않으므로, 이것에 의존하고 싶지 않습니다.
이 문제를 해결할 방법을 찾아보는 것이 좋을 것입니다. 서버에서 어떤 사용자들이 Discourse 스태프(관리자 또는 모더레이터)인지 알고 있다면, 해당 사용자의 SSO 이메일 필드를 실제 이메일 주소로 설정할 수 있습니다. 그들이 가진 중복된 이메일 계정은 가짜 이메일 주소를 받게 될 것입니다.
Discourse에서 스태프가 이메일을 받을 수 있는 것이 유용한 경우가 몇 가지 있습니다. 가장 먼저 마주칠 수 있는 경우는 Discourse가 스태프 사용자를 위해 `/u/admin-login` 라우트를 제공한다는 점입니다. 이 라우트는 스태프 이메일 주소를 입력하는 양식을 표시합니다. Discourse는 해당 스태프에게 일회용 로그인 링크를 보내줍니다. 이는 SSO 설정 시 유용합니다. 설정 과정에서 실수로 사이트에서 잠겨 버린 경우, 이 방법을 통해 다시 로그인할 수 있습니다. 또한 인증 서버에 문제가 발생했을 때도 유용합니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 3, 2024, 8:13오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/25 "2024-05-03T20:13:04Z")
동의합니다. 저는 (Discourse와 무관한 이유로) 이 문제에 대해 생각해 왔습니다. 큰 문제는 일반 멤버가 스태프가 될 수 있고, 실제로 그렇게 된 사례가 있다는 점입니다. 따라서 스태프 사용자에게 고유한 이메일 주소를 요구하더라도, 모든 사용자가 고유한 이메일을 가지고 있는지 보장할 수 없으며, 이는 중복된 이메일을 가진 계정의 사용자가 스태프가 되었을 때 문제를 일으킬 수 있습니다.
그럼에도 불구하고, [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true)가 사용자 조회 시 먼저 고유 ID를 사용한다는 것이 명확해졌고, [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) 게시물에서 “Discourse는 이메일을 사용하여 외부 사용자를 Discourse 사용자와 매핑한다”는 부분은 새로운 SSO 사용자를 기존 Discourse 계정에 연결하는 것에만 해당하며, 로그인 프롬프트 작동 방식에 대한 제 오해가 해소된 지금, 단순히 중복된 이메일 주소를 그대로 전송하는 것을 막는 실질적인 장애물이 있습니까? 아니면 이 고유성이 엄격하게 강제됩니까?
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5월 3, 2024, 8:57오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/26 "2024-05-03T20:57:04Z")
> [@jonbarrow](#):
>
> 중복된 이메일 주소를 그대로 보내는 것을 막는 실질적인 이유가 있나요?
네, 있습니다. 로그인 흐름 설명에서 한 단계를 누락했습니다. Discourse는 먼저 `external_id`를 기반으로 사용자를 찾으려 하고, 그런 다음 `email`을 기반으로 사용자를 찾으려 합니다. 둘 다 찾지 못하면 Discourse는 사용자를 생성하려고 시도합니다. 이것이 Discourse에서 사용자가 처음 등록되는 방식입니다. Discourse는 중복된 이메일 주소를 허용하지 않으므로, 이미 사용 중인 이메일 주소로 사용자를 생성하려는 시도가 이루어지면 Discourse는 오류를 발생시킵니다.
페이로드에 포함된 이메일이 사용자별로 고유하도록 확인해야 합니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 3, 2024, 9:09오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/27 "2024-05-03T21:09:26Z")
확인했습니다. 그 설명에 감사합니다 👍 나중에 사용자의 이메일 주소를 수동으로 업데이트하는 것이 가능한가요? 로그인 프롬프트 문제가 해결되었으므로, 이전에 우리 팀이 구상했던 아이디어를 구현하는 것을 고려해 볼 수 있습니다. 가상의 이메일과 우리가 운영하는 SMTP 서버를 사용하여 그 가상 이메일을 사용자의 실제 이메일로 매핑하는 방식입니다. 예를 들어, 모든 사용자의 Discourse 이메일을 `userid@example.com`과 같은 형태로 업데이트하면, 이 주소가 먼저 SMTP 서버로 연결되고 `userid`를 통해 사용자의 실제 이메일을 조회하게 됩니다. 다만, 이 기능은 상당한 시간이 걸릴 예정이므로, 가능하면 나중에 사용자의 Discourse 이메일을 업데이트할 수 있어야 합니다.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5월 3, 2024, 11:06오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/28 "2024-05-03T23:06:07Z")
> [@jonbarrow](#):
>
> 나중에 사용자의 이메일을 수동으로 업데이트할 수 있을까요?
네, 가능합니다. 이를 위해 `auth overrides email` 사이트 설정을 활성화해야 합니다. 활성화되면 사용자가 로그인할 때마다 사용자의 Discourse 이메일이 인증 페이로드(귀사의 경우 [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) 페이로드)에 포함된 이메일과 동기화됩니다. 활성화되지 않은 경우, 사용자의 이메일은 계정이 처음 생성될 때 인증 페이로드의 이메일로 설정되지만, 이후 로그인 시에는 업데이트되지 않습니다.
`auth overrides email`이 활성화되어 있다고 가정할 때, 사용자가 로그인하지 않고도 `sync_sso` 루트로 API 요청을 보내서 이메일을 업데이트할 수도 있습니다: [Sync DiscourseConnect user data with the sync\_sso route](https://meta.discourse.org/t/sync-discourseconnect-user-data-with-the-sync-sso-route/84398).
사이트의 Rails 콘솔에서 사용자의 이메일 주소를 일괄 업데이트하는 것도 가능합니다. 그러나 (제 생각에는) 이렇게 하면 Discourse에서 사용자에게 확인 이메일이 발송되도록 트리거가 됩니다. 이는 가짜 이메일 주소로는 작동하지 않습니다.
> [@jonbarrow](#):
>
> 예를 들어, 모든 사용자의 Discourse 이메일을 `userid@example.com`과 같은 것으로 업데이트할 것입니다. 이 주소는 먼저 우리의 SMTP 서버로 연결되고, `userid`를 사용하여 사용자의 실제 이메일을 조회합니다. 그러나 이는 상당한 시간이 걸릴 것이므로, 가능하면 나중에 사용자의 Discourse 이메일을 업데이트해야 합니다.
처음부터 의미 있는 이메일 주소를 설정하는 것이 좋을 수도 있습니다. Discourse 사이트 설정을 완료한 후에는, Discourse가 가짜 이메일로 어떤 이메일 도메인을 허용하는지 테스트해 보아야 합니다. 기억에 따르면 `@invalid.com`은 허용되는 것 같습니다. 다른 도메인에 대해서는 확실하지 않습니다. 귀사 측에서는 `@invalid.com`과 같은 것을 사용자의 실제 이메일 주소로 매핑할 수 있습니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 3, 2024, 11:23오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/29 "2024-05-03T23:23:11Z")
정말 incredibly 도움 주셔서 감사합니다! API 솔루션이 제가 생각했던 방향과 일치했지만, 자동으로 동기화될 수 있다는 사실도 완벽하게 마음에 듭니다.
> [@simon](#):
>
> 처음부터 이메일 주소를 의미 있는 것으로 설정하면 어떨까요?
그것도 가능합니다. 처음에는 plus-addressing을 사용해 보려 했거든요. 그러면 적어도 _일부_ 사용자는 처음부터 이메일을 받을 수 있을 테니까요. 그 후, plus-addressing이 작동하지 않는 사용자들을 포함해 모든 사용자를 지원하기 위해 자체 SMTP 매핑 서버로 전환할 계획이었습니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 5, 2024, 2:59오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/30 "2024-05-05T14:59:48Z")
@simon @supermathie 지금까지 정말 많은 도움을 주셨는데, 스레드의 범위를 약간 벗어나서 추가적인 도움을 요청해도 될까요?
[Install Discourse for development using Docker](https://meta.discourse.org/t/install-discourse-for-development-using-docker/102009) 가이드를 참고하여 로컬 머신에 테스트용으로 Discourse를 설치했습니다. 로컬 테스트를 위한 다른 가이드를 찾지 못했습니다. 위키는 프로덕션 환경 설정만 다루고 있는데, 이는 도메인/DNS/SMTP가 이미 설정되어 있어야 합니다. 우리 측에서 모든 구현이 완료될 때까지 포럼을 공개하고 싶지 않았기 때문에, 이러한 설정이 필요 없는 로컬 테스트 환경이 필요했습니다.
해당 가이드를 따라 성공적으로 실행하고 있으며, 사이트의 로컬 인스턴스에서 SSO도 구현했지만, 현재까지 두 가지 문제에 부딪혔습니다:
1. `return_sso_url`로의 리디렉션이 제대로 작동하지 않는 것 같습니다? 제 경우 URL은 `http://localhost:3000/session/sso_login`입니다. 리디렉션은 성공적으로 이루어지지만, 초기 리디렉션 이후에는 `http://localhost:3000`으로 이동하며, 여기서는 `RuntimeError: Discourse does not support compiling scss/sass files via Sprockets`라는 오류가 표시됩니다. 이 오류에 대해 찾을 수 있는 유일한 스레드는 [Error when building: discourse does not support compiling scss/sass files via sprockets](https://meta.discourse.org/t/error-when-building-discourse-does-not-support-compiling-scss-sass-files-via-sprockets/305402) 이지만, 실질적인 해결책은 나오지 않았습니다. 작성자가 어떤 해결책도 채택하지 않았고, RAM과 스왑 크기만 문의했을 뿐입니다(이 머신은 RAM 32GB, 스왑 2GB를 가지고 있습니다. 따라서 이것이 문제일 가능성은 낮다고 생각합니다?)
2. `avatar_force_update`가 무시되고 있는 것 같습니다? 아니면 최소한 관리자 사용자에게는 적용되지 않는 것 같습니다? 사이트 설정에서 `discourse connect overrides avatar`를 활성화했으며, SSO 응답 페이로드에서 `avatar_url`과 `avatar_force_update`를 모두 설정했습니다. 하지만 외부 계정에 연결된 관리자 계정으로 로그인하면 외부 프로필 사진이 표시되지 않습니다? API를 통해 관리자 사용자 데이터를 확인하면 `external_avatar_url`이 올바르게 설정되어 있는 것을 볼 수 있지만, UI에서는 사용되지 않는 것 같습니다?
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5월 5, 2024, 7:35오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/31 "2024-05-05T19:35:39Z")
> [@jonbarrow](#):
>
> 테스트를 위해 로컬 머신에 Discourse를 설치했는데, [Docker를 사용하여 개발용 Discourse 설치](https://meta.discourse.org/t/install-discourse-for-development-using-docker/102009) 가이드를 따랐습니다. 로컬 테스트를 위해 설정하는 방법에 대한 다른 가이드를 찾을 수 없네요?
여기에 설치 방법 목록이 있습니다: [Set up a local Discourse Development Environment?](https://meta.discourse.org/t/set-up-a-local-discourse-development-environment/182882). 저는 Docker를 사용하지 않는 개발 사이트(Ubuntu 가이드 사용)를 사용하고 있습니다. 가능하다면, Docker를 사용하지 않는 방식이 가장 좋은 결과를 얻을 수 있다고 생각합니다. 제가 이 방식을 사용하는 이유 중 하나는 로컬에서 개발 중인 다른 애플리케이션과 Discourse 사이의 API 요청에 대한 네트워크 문제를 처리하지 않아도 되기 때문입니다. 또한 Docker보다 빠릅니다.
> [@jonbarrow](#):
>
> `avatar_force_update`가 무시되는 것 같습니다? 아니면 관리자 사용자에게는 적용되지 않는 건가요?
적용되어야 합니다. SSO 페이로드를 생성하는 애플리케이션에서 부울 값 `true`가 `1`로 변환되지 않도록 확인하십시오. 이는 흔한 문제입니다. 이를 해결하려면 SSO 페이로드의 모든 부울 값을 문자열 `"true"` 또는 `"false"`로 설정할 수 있습니다. Discourse는 이를 올바르게 해석합니다. 먼저 이것이 문제인지 확인해 보세요. 다른 문제일 수도 있습니다. `avatar_force_update`를 처리하는 코드는 다소 복잡하지만 읽을 수 있습니다: [discourse/app/models/discourse\_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/187204705323b650d61ed25862eb1a0c733aa63c/app/models/discourse_connect.rb#L361-L375).
수정: SSO 페이로드의 부울 값 문제에 대해, SSO 페이로드 생성 과정에서 환경이 부울 값 true/false를 문자열로 변환한다고 말하는 것이 더 정확할 것입니다. Discourse는 문자열이 `"true"` 또는 `"false"`일 것을 기대하지만, 다른 프로그래밍 환경에서는 다르게 처리할 수 있습니다. 예를 들어:
PHP:
```php
wp> strval(true)
=> string(1) "1"
```
반면에 Ruby:
```ruby
irb(main):001> true.to_s
=> "true"
```
Python (Discourse가 이 경우를 어떻게 처리하는지는 확실하지 않습니다):
```python
>>> str(True)
'True'
```
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 6, 2024, 12:55오전 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/32 "2024-05-06T00:55:39Z")
> [@simon](#):
>
> 가능하다면, Docker를 사용하지 않는 방식을 사용하는 것이 가장 좋은 결과를 얻을 수 있을 것이라고 생각합니다.
이 중 하나를 시도해 보겠습니다. 그 방향으로 안내해 주셔서 감사합니다. 다만, 이는 상당히 직관에 반하는 내용입니다. 보통 사람들은 설정을 “간편하고 빠르게” 하려면 Docker 솔루션을 _찾아_ 보려는 경향이 있습니다. Docker 버전을 _피하라는_ 권고를 받은 것은 이번이 처음입니다. 하지만 여전히 Docker 버전에서 왜 이런 일이 발생하는지에 대한 질문이 남습니다. 문제를 우회하기 위해 다른 설치 방법을 사용하는 것은 당장은 작동하지만, 근본적인 문제를 해결하지는 못합니다.
> [@simon](#):
>
> 그렇습니다. SSO 페이로드를 생성하는 애플리케이션이 부울 값 `true`를 `1`로 변환하지 않도록 확인하십시오.
`1`로 설정되지 않는 것이 확실합니다. 저는 JavaScript로 작업하고 있으며, 부울 값 `true`는 항상 문자열 `"true"`로 문자열화됩니다:
```js
String(true); // 'true'
(true).toString(); // 'true'
// 이것이 제 코드가 실제로 사용하는 것입니다
querystring.stringify({
avatar_force_update: true
}); // 'avatar_force_update=true'
```
> [@simon](#):
>
> `avatar_force_update`를 처리하는 코드는 다소 복잡하지만, 읽을 수 있습니다: [discourse/app/models/discourse\_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/187204705323b650d61ed25862eb1a0c733aa63c/app/models/discourse_connect.rb#L361-L375).
저는 Ruby로 작업해 본 적이 없어서, 실제로 이 문제를 파고들어서 얼마나 멀리 갈 수 있을지 확실하지 않습니다. 하지만 대충 살펴본 결과, 문제를 발견하지 못했습니다. 그러나 _확인해 본_ 결과, Discourse 대시보드의 관련 설정과 SSO 페이로드 모두 설정되어 있습니다:
표준 사용자 계정의 이미지를 계정 생성 시 사용된 것에서 다른 것으로 변경하려는 시도를 테스트해 보지는 않았지만, 표준 사용자 계정으로 처음 로그인했을 때 Discourse는 아바타를 다운로드하고 예상대로 적용했습니다. 업데이트되지 않는 유일한 계정은 관리자 계정입니다?
> [@simon](#):
>
> PHP:
>
> ```php
> wp> strval(true)
> => string(1) "1"
>
> ```
솔직히 말해서, PHP에서는 변수의 “실제” 문자열 표현을 얻으려면 거의 항상 `var_export`를 사용해야 합니다. 이는 해당 변수를 다시 생성하는 데 필요한 유효한 PHP 코드를 반환하기 때문입니다:
```php
var_export(true); // true
```
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5월 6, 2024, 1:09오전 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/33 "2024-05-06T01:09:55Z")
사용자 관리자 페이지 하단의 [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) 섹션을 확인해 보세요. 클릭하면 Discourse가 마지막으로 받은 SSO 페이로드의 값이 확장되어 표시됩니다.
Rails 콘솔에서도 동일한 정보를 찾을 수 있습니다. 예를 들어:
```ruby
>SingleSignOnRecord.last
# 또는
>SingleSignOnRecord.where(external_id: 2)
```
`verbose discourse connect logging` 사이트 설정을 활성화해야 합니다. 이 설정은 Admin / Logs / Error Logs에서 생성되는 로그에 추가적인 세부 정보를 제공합니다. 아바타 문제의 경우, 관련 로그 항목이 [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) 로그가 아닌 일반 오류 로그로 표시될 수 있습니다.
> [@jonbarrow](#):
>
> 솔직히 말하자면, PHP에서는 변수의 “진짜” 문자열 표현을 얻으려면 거의 항상 `var_export`를 사용해야 합니다.
이 문제는 WordPress에 고유한 것일 수 있습니다. WordPress는 `true`에 대해 항상 `1`을 반환하고, `true`의 문자열 표현에 대해서는 `"1"`을 반환합니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 6, 2024, 2:09오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/34 "2024-05-06T14:09:45Z")
> [@simon](#):
>
> 사용자 관리 페이지 하단에 있는 [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) 섹션을 확인해 보세요. 클릭 시 확장되어 Discourse가 마지막으로 받은 SSO 페이로드의 값을 보여주는 버튼이 있습니다.
기대했던 페이로드이며, 프로필 사진 URL이 올바르게 표시됩니다:
프로필 사진은 이 이미지가 되어야 합니다:
하지만 여전히 이렇게 표시됩니다:
이것은 제 Gravatar입니다:
이 설정을 잘못 이해하고 있거나, 추가로 설정해야 할 다른 사항이 있는 것이 아니라면, 이 값들을 오버라이드하도록 설정을 활성화했습니다:
캐싱 문제가 아닌지 확인하기 위해 시크릿 모드, 다른 브라우저, 브라우저 캐시 삭제도 시도해 보았습니다.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5월 6, 2024, 3:14오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/35 "2024-05-06T15:14:03Z")
이것이 로컬 개발 사이트에서 발생한 건가요?
아바타 업로드가 어떤 이유로 실패한 것 같습니다. `verbose discourse connect logging` 사이트 설정을 활성화한 후, 로그아웃을 하고 다시 로그인해 보세요. 로그에는 아바타와 관련된 메시지가 최소 하나 이상 표시되어야 합니다:
>
업로드 실패와 관련된 다른 오류가 있을 수도 있습니다.
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [5월 6, 2024, 3:25오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/36 "2024-05-06T15:25:35Z")
> [@jonbarrow](#):
>
> RuntimeError: Discourse does not support compiling scss/sass files via Sprockets
아직 파악하지 못하셨다면, 이 메시지는 "브라우저를 통해 직접 접근하는 대신 `ember-cli` 프록시를 통해 접근해야 한다"는 뜻입니다.
개발용 서버를 시작하려면 `bin/ember-cli -u`를 사용하세요.
질문자님의 아바타 문제를 재현해 보았습니다:
수정 전:
로그인 페이로드:
수정 후:
하지만:
Discourse가 사용자 정의 아바타 URL을 올바르게 설정하는 반면, _Gravatar에서 사용자 정의 이미지로 전환하지 않는_ 버그라고 생각합니다.
새로운 사용자를 생성하면:
바로 정상 작동합니다:
따라서 이 문제는 [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true)를 사용하기 _이전_에 Gravatar가 설정된 계정을 가진 경우 발생하는 것으로 추정됩니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 7, 2024, 7:10오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/37 "2024-05-07T19:10:46Z")
> [@simon](#):
>
> 가능하시다면, Docker를 사용하지 않는 방식으로 진행하시는 것이 가장 좋은 결과를 얻으실 수 있을 것입니다.
조금의 조정이 필요했지만(설치 스크립트가 이미 설치된 패키지 및 소프트웨어와 충돌했기 때문), Ubuntu 단계를 성공적으로 적용했습니다. 원래 발생하던 오류는 해결되었지만 SSO는 여전히 절반만 작동합니다. 이제 scss/sass 오류 대신 SSO에서 매번 `Account login timed out, please try logging in again.`(계정 로그인 시간 초과, 다시 로그인해 주세요) 오류가 발생합니다. 다만 이 오류 화면에서 `Login`(로그인) 버튼을 두 번째로 클릭하면 로그인이 완료됩니다. 제 쪽에서는 코드 변경이 없었으며, Discourse가 실행되는 방식만 바뀌었습니다.
이 모든 것을 로컬에서 실행할 때의 특이점으로 넘기려고 합니다. 프로덕션 배포에서는 이러한 문제가 발생하지 않기를 바랍니다.
> [@supermathie](#):
>
> 아직 파악하지 못하셨다면, 이것은 "브라우저를 직접 사용하는 대신 `ember-cli` 프록시를 통해 접근해야 한다"는 뜻입니다.
>
> 개발을 위해 실행하려면 `bin/ember-cli -u`를 사용하세요.
Docker 버전에서는 이것이 아무런 효과를 내지 않는 것 같았습니다. 스크립트가 출력이 없이 종료되었고, Discourse 쪽에서도 실제로 아무 일이 일어나지 않는 것 같았습니다. 또한 이는 Docker 가이드에 나열된 단계와도 모순되며, 이는 다소 이상하게 느껴집니다. 여기에 언급되지 않은 이유가 있을까요?
Docker 방식에 이러한 문제가 있고, 공식 권장 사항이 Discourse를 네이티브로 설치하는 것(설치 스크립트가 항상开箱即用으로 작동하지는 않으며, `bashrc` 사용과 같은 사항을 전제로 하고 이미 설치된 패키지와 충돌할 수 있는 버전의 패키지를 설치하려고 시도하기 때문)이라는 것이 이상하게 느껴집니다. 사용 가능한 모든 호스팅 버전에 잠재적 문제에 대한 경고가 있어야 하지 않을까요? 한눈에 봐도 어떤 것을 선택해야 하는지 명확하지 않으며, 일반적으로 Docker 빌드가 제공되면 그것이 기본 선택지가 되어야 한다고 생각하는 경향이 있습니다.
> [@supermathie](#):
>
> 여러분의 아바타 상황을 재현했습니다.
나만 그런 게 아니라는 점이 다행입니다! 😃 버그는 항상 재미있지 않지만, 이 버그를 찾는 데 도움이 되어 기쁩니다.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5월 7, 2024, 7:31오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/38 "2024-05-07T19:31:05Z")
> [@jonbarrow](#):
>
> 이 모든 것을 로컬에서 실행할 때의 특이한 현상 정도로 치부할 생각입니다. 프로덕션 배포에서는 이러한 문제가 발생하지 않기를 바랍니다.
그럴 수도 있지만, 로컬 환경에서 [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true)를 아무 문제 없이 작동시킬 수 있어야 합니다. 현재 `http://localhost:4200` 으로 Discourse에 접근하고 계신가요? 로컬 개발 환경에서는 `localhost:4200` 이나 `127.0.0.1:4200` 중 어느 주소로든 Discourse에 접근할 수 있는 이상한(제 생각에는) 문제가 있습니다. `localhost` 도메인을 사용하는 것이 좋습니다. `127.0.0.1` 과는 별도의 세션으로 처리되거든요.
어쨌든, 이것은 현재 상황에 대한 추측일 뿐입니다. 자세한 내용을 확인하려면 상세 로깅 설정을 활성화하고 로그를 살펴보세요.
> [@jonbarrow](#):
>
> 설치 스크립트가 이미 설치된 패키지와 소프트웨어와 충돌했습니다)
설치 지침에는 스크립트를 실행할 필요가 없음을 명확히 해야 합니다. 스크립트를 단계별로 진행하여 모든 종속성이 설치되었는지 확인하면 됩니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 7, 2024, 7:43오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/39 "2024-05-07T19:43:38Z")
> [@simon](#):
>
> `http://localhost:4200`에서 Discourse에 액세스하고 계신 건가요?
네, 맞습니다.
> [@simon](#):
>
> 설치 지침에는 스크립트를 실행할 필요가 없다는 점이 명확히 나와 있어야 합니다.
이전에 링크된 지침에는 이 부분이 명확하지 않습니다. [https://meta.discourse.org/t/set-up-a-local-discourse-development-environment/182882로](https://meta.discourse.org/t/set-up-a-local-discourse-development-environment/182882%EB%A1%9C) 이동한 뒤, 제가 Ubuntu 22.04.3을 사용 중이므로 [https://meta.discourse.org/t/install-discourse-on-ubuntu-or-debian-for-development/14727를](https://meta.discourse.org/t/install-discourse-on-ubuntu-or-debian-for-development/14727%EB%A5%BC) 선택했습니다. 이 페이지에는 전체 스크립트를 실행할 필요가 없다는 내용이 있지만, 사용자가 실행하도록 지시하는 부분 _이후_에 작은 글씨로만 언급되어 있습니다.
저에게는 이것이 명확하지 않았습니다. 지침을 위에서부터 아래로 읽으면 자연스럽게 현재 단계를 완료해야 다음으로 넘어갈 수 있다고 가정하게 되거든요. 그래서 저는 설치 스크립트와 씨름하며 필요한 것만 설치했고, 끝까지 진행한 후에야 처음부터 의도된 방식이었으며 실제로 씨름할 필요가 없었음을 알게 되었습니다.
해당 면책 조항(또는 주의 사항)을 지침 _이후_에 배치하는 것은 제 생각에 지침을 명확하게 하지 않습니다.
---
### Author:  [@jonbarrow](https://meta.discourse.org/u/jonbarrow)
#### Post date: [5월 7, 2024, 7:51오후 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/40 "2024-05-07T19:51:08Z")
> [@simon](#):
>
> 상세 로깅 설정을 활성화하고 로그를 확인하여 세부 사항을 살펴보세요.
nonce가 올바르지 않다고 판단하는 것 같습니다. 로그인 시 로그에서 다음 내용을 확인하고 있습니다:
```plaintext
Can't verify CSRF token authenticity. 3:44 pm
Verbose SSO log: Started SSO process add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 3:44 pm
Verbose SSO log: Nonce is incorrect, was generated in a different browser session, or has expired add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784 3:44 pm
Verbose SSO log: Started SSO process add_groups: admin: avatar_force_update: avatar_url: bio: card_background_url: confirmed_2fa: email: external_id: failed: groups: locale: locale_force_ 3:44 pm
Verbose SSO log: User was logged on PN_Jon add_groups: admin: avatar_force_update: true avatar_url: https://pretendo-cdn.b-cdn.net/mii/1424784406/normal_face.png bio: card_background_url: confirm 3:44 pm
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-City.mmdb) could not be found: No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-City.mmdb 3:44 pm
MaxMindDB (/home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb) could not be found: No such file or directory @ rb_sysopen - /home/jon/discourse/vendor/data/GeoLite2-ASN.mmdb 3:44 pm
```
더 자세히 살펴본 결과, SSO 리다이렉트가 `localhost`를 _사용하지 않고_ 있기 때문인 것으로 보입니다. 대신 `127.0.0.1`으로 되돌려 보내고 있습니다. 처음부터 `localhost` 대신 `127.0.0.1`을 사용하도록 변경하면 문제가 해결됩니다.
[이전 페이지](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489.md?page=1)
[다음 페이지](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489.md?page=3)