이것이 사용자 관련 슬러그(사용자명을 포함하는 경우)에도 영향을 줄 수 있을까요?
UTF-8 사용자명을 사용하는 몇몇 사용자가 자신의 프로필에 접근하지 못하는 문제가 있습니다…
2개의 좋아요
경로가 완전히 다르므로 사용자에는 전혀 영향을 주지 않아야 합니다.
프로필이 로드되지 않는 링크를 공유해 주시겠습니까? 아니면 버그가 발생하는 사용자 이름의 예시를 알려 주시겠습니까?
4개의 좋아요
2개의 좋아요
이 페이지가 Cloudflare 프록시 뒤에 있나요? 프록시를 꺼놓고 테스트해 보실 수 있을까요?
또한 다음 설정 값은 무엇인가요?
-
allowed unicode username characters(허용되는 유니코드 사용자 이름 문자) -
unicode usernames(유니코드 사용자 이름)
3개의 좋아요
값은 다음과 같습니다 (꽤 표준적인 값입니다 
)
네
방금 프록시를 비활성화하고 다시 테스트했습니다. 불행히도 문제가 여전히 지속됩니다. 원하시는 경우 직접 테스트하실 수 있도록 프록시를 잠시 비활성화한 상태로 유지하겠습니다 
도와주셔서 정말 감사합니다! 
2개의 좋아요
음.
대문자를 로드하려고 하면 처음에는 https://rembetiko.gr/u/ΣΠΥΡΟΣ가 로드되지만, 이후 소문자 버전으로 JSON을 가져오는 과정에서 실패합니다.
대소문자 처리 과정에서 오류가 있는 것 같습니다.
6개의 좋아요
이상하게도 이 하나는 작동합니다:
https://rembetiko.gr/u/αγγελικη_ντοτη
사용자 이름은 ΑΓΓΕΛΙΚΗ_ΝΤΟΤΗ입니다 (다시 말해 αγγελικη_ντοτη의 대문자 형태입니다).
2개의 좋아요
그리스어에서 대문자 'Σ’를 소문자로 표기하는 방법이 두 가지일 수 있을까요?
- 단어의 끝에서 사용할 때: ‘ς’
- 그 외의 모든 위치에서: ‘σ’
2개의 좋아요
그래서 이건 잘못된 건가요?
[1] pry(main)> "ΣΠΥΡΟΣ".downcase
=> "σπυροσ"
2개의 좋아요
네, 문법적으로 틀렸습니다. 올바른 형태는 "σπυρος"입니다.
2개의 좋아요
아, 죄송하지만 이것은 Ruby의 버그인 것 같습니다:
➜ ruby --version
ruby 3.0.0dev (2020-12-16T18:46:44Z master 93ba3ac036) [x86_64-linux]
➜ irb
irb(main):001:0> "ΣΠΥΡΟΣ".downcase
=> "σπυροσ"
3개의 좋아요
하지만 링크가 생성되면 잘 작동합니다… 그러니까 작동하는 방법이 있을 텐데요… (?)
2개의 좋아요
Ruby가 사용자 이름을 문법적으로 올바른 소문자 버전으로 변환하더라도, 항상 정규화된 사용자 이름(User.normalize_username in Ruby)과 데이터베이스의 username_lower를 기준으로 사용자를 조회하는 한 문제는 되지 않아야 합니다.
어떤 JSON fetch가 실패할까요? 사용자 이름 비교에 다른 메커니즘을 사용하는 라우트가 존재할 가능성이 매우 높습니다.
4개의 좋아요
Ruby와 JS의 구현 방식이 다르기 때문일까요?
➜ ruby --version
ruby 3.0.0dev (2020-12-16T18:46:44Z master 93ba3ac036) [x86_64-linux]
➜ irb
irb(main):001:0> "ΣΠΥΡΟΣ".downcase
=> "σπυροσ"
➜ node
Welcome to Node.js v12.11.1.
Type ".help" for more information.
> "ΣΠΥΡΟΣ".toLowerCase()
'σπυρος'
제 테스트에서 Firefox도 NodeJS와 동일한 결과를 반환합니다.
엔드포인트 /u/#{username}.json은 username_lower 컬럼이 아닌 username 컬럼만 반환하므로, 여기서 브라우저에 의존하고 있는 것은 아닌지 의심됩니다. 지금 조사 중입니다…
6개의 좋아요
아, 그건 좀 문제가 있겠네요. 그래서 문제는 아마 이 부분일 거예요:
클라이언트에서 처리하는 대신 서버에서 UserSerializer에 username_lower를 추가하는 것을 제안하려고 했었지만, 그렇게 해도 username.toLowerCase가 사용되는 다른 몇몇 지점들은 여전히 남아있게 됩니다.
비-ASCII 문자가 포함된 경우 서버에서 mini_racer를 사용하여 username_lower를 계산하는 것이 더 나은 해결책이 될 수 있을지 궁금합니다. 
6개의 좋아요
음, 우리가 추구하고 있는 우회책과 무관하게 이 문제를 Ruby에 보고하겠습니다.
8개의 좋아요
참고로 PHP도 Ruby와 동일한 방식으로 처리합니다… 이는 의도적인 설계(?)인 것 같습니다.
아래에서 코드를 테스트해 볼 수 있습니다:
1개의 좋아요
흥미롭게도 Postgres도 여기서 실패합니다:
[2] pry(main)> DB.query_single('select lower(?)', 'ΣΠΥΡΟΣ')
=> ["σπυροσ"]
username_lower 계산을 처리하는 내부 Discourse 메서드에서 이 특이한 경우를 특별 처리하는 것이 좋을까요?
username_lower를 호출하는 모든 메서드를 찾아 중앙 함수로 전달하고, 그 함수에서 이 특별 처리를 허용하도록 하면 됩니다 (원한다면 mini_racer 호출을 사용하거나, 단순히 .lower를 호출한 후 sub 호출로 후처리하여 수정할 수 있습니다)
더 명확하도록 OP 제목을 업데이트합니다.
3개의 좋아요
주어진 예:
[4] pry(main)> "σπυρος".downcase
=> "σπυρος"
@chrispanag 님, 아주 단순한 우회 방법은 사용자 이름을 σπυρος로 변경하는 것입니다. 그러면 username과 username_lower가 완전히 동일해지며, 이 문제는 자연스럽게 해결됩니다.
이 특정 사례를 위해 코어에 우회 방법을 추가하는 것에 대해서는 의견이 갈립니다. 특히 전혀 어려운 일이 아닌 우회 방법이 이미 존재하는 상황에서 더욱 그렇습니다.
추가적으로, allowed unicode username characters 설정을 통해 사용자 이름에서 Σ 문자의 사용을 금지할 수도 있습니다. 이렇게 하면 이 문제가 다시 발생하지 않도록 보장할 수 있습니다.
모두 Ruby와 Postgres를 수정하기 위함이지만, 이러한 문제를 해결하기 위해서는 수년에 걸친 긴 싸움이 필요합니다.
5개의 좋아요
전적으로 동의합니다. 우리는 업스트림 버그를 보고하고, 그 동안 Discourse 사용자는 기존 도구를 사용하여 우회할 수 있습니다.
5개의 좋아요