*ChatGPT로 번역되었음

원문 (영어) 참고: https://private-raw.abstr.net/discuss.txt

그리핑 = 계정 등록 남용 행위

[DCSS admin-private 채널에 입장]

gammafunk — 오늘 오전 6:23

@ASCIIPhilia 이 채널을 볼 수 있고 비공개로 유지하고 싶은 관리자 문제를 논의할 수 있을 것입니다.

ASCIIPhilia — 오늘 오전 6:25

초대해 주셔서 감사합니다.

gammafunk — 오늘 오전 6:25

@ASCIIPhilia 사용자 DB를 공유할 때 비밀번호/이메일에 대한 문제는 예, 보안 문제일 수 있습니다. 그러나 궁극적으로 서버 관리자에게 사용자 데이터를 신뢰하는 것과 다르지 않습니다.

궁극적으로 각 서버 관리자는 자신의 사용자 데이터에 대해 책임을 집니다.

하지만 기존 DB를 사용하는 이유는 대다수 사용자의 그리핑을 방지하기 위함입니다. 물론 이는 미국 사용자에게만 효과가 제한됩니다.

기존 사용자 데이터베이스를 가져오고 싶지 않다고 강력하게 느끼신다면, 당연히 새 데이터베이스로 시작할 수 있도록 허용하겠습니다. 새로운 서버가 있다는 것을 사용자에게 통지할 것입니다.

하지만 괜찮으시다면 기존 데이터베이스로 시작하는 것이 도움이 됩니다.

ASCIIPhilia — 오늘 오전 6:28

```

ASCIIPhilia

어제 서버 작업을 마치고 PR을 제출한 후, 한국 로그라이크 커뮤니티에 새 서버가 열렸고 Sequell에 PR이 요청되었다고 게시했습니다. 그리고 잠자리에 들었습니다. 그런데 오늘 Roguelikes @dcss 채널을 확인해보니 이름 선점에 대한 우려가 있었습니다. 로그를 확인해보니 아직 그러한 문제가 발생하지 않은 것 같습니다. 하지만 제가 취해야 할 조치가 있을까요? (예: 공지가 나가기 전까지 계정 등록을 일시적으로 비활성화하는 것 등)

ASCIIPhilia — 오늘 오전 6:14

아직 아무도 본격적으로 게임을 시작하지 않은 것 같으니, 만약 등록을 제한하거나 데이터베이스를 초기화해야 한다면 혼란을 최소화하기 위해 가능한 빨리 이를 공지하고 싶습니다 (예: 사람들에게 아직 등록하지 말라고 알리는 것 등).

아니면 제가 걱정할 필요가 없는 일에 과민 반응을 보이는 건가요?

gammafunk — 오늘 오전 6:19

아, 네, 좋은 지적입니다.

기존 서버의 사용자 DB로 시작하는 것이 이상적입니다.

그렇게 하면 선점/그리핑이 발생할 수 있는 가능성이 최소화됩니다.

몇 달 전의 cbr2 데이터베이스 복사본이 있지만, 더 최근의 복사본을 구할 수 있습니다.

이 문제를 해결하는 한 가지 방법은 cbr2 사용자 DB의 복사본을 받아서 현재의 DB에 설치한 후, 그 다음에 등록을 진행하는 것입니다.

대안은 사람들이 연승 기록에 신경을 쓴다면 등록하라고 말하는 것이지만, 과거에 이와 관련된 문제가 있었습니다.

개발 디스코드의 관리자 비공개 채널에 당신을 추가해도 괜찮을까요?

ASCIIPhilia — 오늘 오전 6:24

비밀번호가 해시화되어 있어도, 마이그레이션이 아닌 새로운 서버 출시에 이를 공유하는 것은 보안 문제일 수 있다고 생각해서 불가능할 것이라고 생각했습니다.

ASCIIPhilia — 오늘 오전 6:24

네, 물론입니다.

gammafunk — 오늘 오전 6:24

좋습니다, 그럼 거기서 계속 논의합시다.

```

이 문제를 이해하고자 하는 분들을 위해 이전 대화를 첨부합니다.

gammafunk — 오늘 오전 6:28

네, 처음에 @PleasingFungus가 언급했던 것 같습니다.

사실 생각해보니 DB를 공유하는 것은 처음부터 좀 더 복잡한 문제입니다.

PleasingFungus — 오늘 오전 6:32

DB를 공유하는 것에 대한 보안 문제는 당연히 이해합니다.

gammafunk — 오늘 오전 6:32

지난번에 Zureal과 저는 비밀번호로 보호된 다운로드를 통해 저장소를 다운로드하는 방법을 해킹했지만, 이는 ASCIIphilia와는 작동하지 않습니다.

PleasingFungus — 오늘 오전 6:32

이는 제게도 마음에 들지 않는 상황입니다.

하지만 명확히 하자면, 새로운 DB로 시작하는 것은 기존의 보안 문제가 있습니다.

우리는 서버 간에 점수를 공유합니다.

따라서 새 서버를 새 DB로 시작하면 모든 계정이 비밀번호 보호 없이 남게 됩니다.

그리고 플레이어들은 '그리핑' 당하지 않기 위해 새로운 서버에서 계정을 다시 등록해야 합니다.

ASCIIPhilia — 오늘 오전 6:34

다른 서버에 등록했지만 계정을 찾을 수 없는 사용자에게는 동일한 닉네임으로 등록할 기회가 차단됩니다.

모든 서버의 데이터베이스가 처음부터 통합되지 않았기 때문에 각 서버에 이미 다른 사람이 소유한 계정이 있을 가능성이 큽니다. (이 경우 주식처럼) (특정 서버의 소유자가 자신의 계정을 내 서버에서 예약해야 한다고 주장할 권리가 없지 않나요? 결국, 복사하려면 여러 서버 중 하나의 데이터베이스를 선택해야 합니다.)

PleasingFungus — 오늘 오전 6:35

다른 서버에 등록했지만 계정을 찾을 수 없는 사용자에게는 동일한 닉네임으로 등록할 기회가 차단됩니다.

이해하지 못하겠습니다. 다시 설명해 주실 수 있나요?

모든 서버의 데이터베이스가 처음부터 통합되지 않았기 때문에 각 서버에 이미 다른 사람이 소유한 계정이 있을 가능성이 큽니다.

네.

특정 서버의 소유자가 자신의 계정을 내 서버에서 예약해야 한다고 주장할 권리가 없지 않나요?

네?

우리는 여러 서버 중 하나의 데이터베이스를 선택해야 합니다.

물론입니다. 하지만 그게 무슨 해가 될까요?

ASCIIPhilia — 오늘 오전 6:37

예외적인 경우에 대해 말하고 있습니다. 예를 들어, 내가 CWZ에서 ASCIIPhilia로 등록했지만 비밀번호와 가입에 사용한 이메일을 잊어버렸다고 가정해 봅시다. 나는 CWZ에 등록했음을 확신하지만, 새로운 서버가 CWZ의 데이터베이스를 상속받으면 다시 등록할 수 있는 대신 또 다른 서버에서 내 계정을 잃어버리게 됩니다.

PleasingFungus — 오늘 오전 6:37

물론입니다. 하지만 그건 현 상태와 다를 바 없습니다.

단순히 asciiphilia2로 등록할 수 있습니다. 조금 슬프긴 하지만, 그게 현실입니다.

반면, 대안은 트롤이 asciiphilia로 등록하고 통계를 조작할 수 있다는 것입니다.

크롤에서 잠시 휴식을 취하거나 디스코드에 없는 상황에서 새로운 서버 공지를 놓치면 어떻게 될까요?

그 후 다음 토너먼트를 위해 돌아옵니다.

다음 토너먼트에서 게임을 하는 동안, 트롤이 당신의 연승 기록을 보고 새로운 서버에서 당신의 이름으로 계정을 등록하고 연승을 깨뜨립니다.

이것은 가상의 상황이 아닙니다. 실제로 여러 번 발생한 일입니다.

이것은 매우 혼란스럽고 해결하기 번거롭습니다.

gammafunk — 오늘 오전 6:40

물론 미국 서버 DB를 사용하는 것은 이 문제를 해결하지 못합니다. 특히 CWZ 플레이어는 cbr2에 등록되지 않을 수 있습니다.

하지만 많은 플레이어에게는 도움이 됩니다.

그리고 지금 시점에서는 CDI 데이터베이스를 사용하는 것이 가장 좋을 것 같습니다. asciiphilia를 임시로 dgl 관리자로 만들어 db 공유를 더 쉽게 설정할 수 있기 때문입니다.

PleasingFungus — 오늘 오전 6:41

네, 그리고 만약 누군가가 미국 서버를 이용해 비미국 플레이어의 연승을 깨뜨리고 싶다면, 이미 cbr2 등을 사용할 수 있습니다.

ASCIIPhilia — 오늘 오전 6:41

그래서 조금 번거롭지만 똑똑한 방법이 있을 것 같아요:

1. 예약 기회 제공 (선점)

2. 이름 선점 최소화

서버 시작 초기 기간(며칠 또는 몇 주 동안)에 특별한 등록 백엔드를 만들어서 다른 서버에 등록된 사용자가 먼저 내 서버에 등록할 기회를 제공할 수 있습니다.

이 기간 동안 내 서버에 등록하려면 다른 서버에 등록되지 않은 계정을 등록하거나, 다른 서버에 이미 등록된 경우 그 서버 중 하나에 로그인하여(백엔드에서 처리) 등록을 인증해야 합니다.

특별 백엔드 기간이 끝나면 누구나 자유롭게 등록할 수 있습니다.

이렇게 하면 여러 소유권 주장이 있는 계정에 대해 처음으로 예약한 사람이 계정을 얻게 되어 많은 측면에서 가장 공정한 방법이 됩니다.

특별 백엔드 기간이 끝나면 이러한 특권도 끝납니다. 따라서 이 측면에서도 공정합니다.

이 등록 백엔드 프로그램은 향후 다른 새로운 서버 출시에도 유용할 수 있습니다.

ASCIIPhilia — 오늘 오전 6:50

우선, 우리가 사용할 방법을 결정할 때까지 잠재적인 문제를 방지하기 위해 서버를 중단하겠습니다.

gammafunk — 오늘 오전 6:51

그래서 기존 서버, 사용자 이름, 비밀번호를 입력하고, 제공한 자격 증명을 사용하여 해당 서버에서 인증할 수 있다면 등록을 허용하는 것인가요?

ASCIIPhilia — 오늘 오전 6:51

네

gammafunk — 오늘 오전 6:51

그렇다면 어떻게 계정이 기존에 등록되어 있는지 알 수 있나요?

ASCIIPhilia — 오늘 오전 6:52

백엔드에서 WebSocket을 통해 로그인 시도를 할 수 있습니다.

gammafunk — 오늘 오전 6:52

아니, 그러니까 다른 서버에 등록되지 않은 계정의 경우를 말한 겁니다.

그렇다면 어떻게 알 수 있나요?

다른 서버에 등록되지 않은 임의의 새 계정을 주면, 실제로 그 계정이 어떤 서버에도 등록되지 않았다는 것을 어떻게 알 수 있나요?

ASCIIPhilia — 오늘 오전 6:54

사용자 파일이 다른 서버에 등록되지 않았는지 확인하는 것으로 충분하지 않을까요?

gammafunk — 오늘 오전 6:54

사용자 파일?

ASCIIPhilia — 오늘 오전 6:54

https://archive.nemelex.cards/morgue/ASCIIPhilia

gammafunk — 오늘 오전 6:54

글쎄요, 이는 실제로 등록을 확인하는 방법이 아닙니다.

이는 사용자가 해당 서버에서 게임을 한 적이 있는지를 확인하는 방법일 수 있습니다.

하지만 등록만 하고 게임을 하지 않으면 특별한 파일이나 디렉터리가 존재하지 않을 수 있습니다.

제가 몇 분 전에 nemelex.cards에 등록했습니다.

공개적으로 확인할 수 있는 어떤 것도 서버에 가지고 있는지 확실하지 않습니다.

이제 rc 파일이 생겼습니다.

ASCIIPhilia — 오늘 오전 6:56

https://archive.nemelex.cards/rcfiles/crawl-0.31/gammafunk.rc

맞아요.

gammafunk — 오늘 오전 6:57

네, 특정 디렉터리를 확인할 수는 있겠지만, 각 서버마다 고유의 디렉터리 구조가 있습니다.

이 아이디어는 구현할 의사가 있다면 좋은 방법입니다.

@advil이 이 제안에 대해 어떻게 생각하는지 궁금합니다 (⁠admin-private⁠ 참조).

이 방법이 타이밍 문제를 완전히 해결하지는 않습니다. 예를 들어 6개월 후에 dcss로 돌아오는 사람들은 운이 없을 것입니다.

유예 기간이 필요할 것 같습니다. 한 달 정도? 며칠 이상은 분명히 필요할 것입니다.

ASCIIPhilia — 오늘 오전 7:00

그 기간(6개월)을 감안하면, 최대한 고려한 것이라고 생각합니다.

제안된 기간은 그냥 제안일 뿐이며, 필요하면 연장할 수 있습니다.

gammafunk — 오늘 오전 7:00

맞아요.

결국, 서버에 이 백엔드를 구현하고 싶다면 우리는 반대하지 않을 것입니다. 단순히 데이터베이스를 공유하는 것보다 몇 가지 중요한 측면에서 개선된 것처럼 들립니다.

advil의 의견도 듣고 싶습니다. 그는 많은 인프라 관련 문제에 대해 조언을 해주었습니다.

ASCIIPhilia — 오늘 오전 7:11

이전에 Node.js로 PublicControlBot 같은 것을 만들어본 적이 있어서 WebSocket 기반의 등록 확인은 그렇게 어렵지 않을 것 같습니다. 하지만 서버 DB 파일에 어떻게 접근해야 하는지는 잘 모르겠습니다. 아직 조사해보지 않았지만 SQLite를 사용하나요?

만약 SQLite를 사용한다면, 특별한 라이브러리가 아닌 표준 sqlite3 라이브러리로 작업하는 것이 어렵지 않을 것입니다.

ASCIIPhilia — 오늘 오전 7:27

CAO 서버가 셧다운되었나요?

gammafunk — 오늘 오전 7:30

네, 표준 sqlite3 라이브러리를 사용해서 조작할 수 있는 간단한 sqlite 데이터베이스입니다.

gammafunk — 오늘 오전 7:31

아니요, https://crawl.akrasiac.org:8443/' target="_blank">https://crawl.akrasiac.org:8443/#lobby에서 접속 가능합니다.

새 HTTP URL을 사용하지 않으신 것 같습니다.

옛 URL은 https를 지원하지 않았습니다.

ASCIIPhilia — 오늘 오전 7:32

저는 webtiles.akrasica.org을 사용했습니다.

이 URL에서는: https://crawl.develz.org/wordpress/howto

gammafunk — 오늘 오전 7:32

아, 네, 아마도 http를 사용해서 작동하지 않는 것 같습니다.

그 URL을 업데이트해야겠네요. 현재 URL은 https://crawl.akrasiac.org:8443/' target="_blank">https://crawl.akrasiac.org:8443/ 입니다.

아, 사실 webtiles.akrasiac.org도 작동했습니다.

gammafunk — 오늘 오전 7:34

https://crawl.akrasiac.org:8443/' target="_blank">https://crawl.akrasiac.org:8443/를 사용해야 합니다. 그 페이지의 URL을 업데이트하겠습니다.

ASCIIPhilia — 오늘 오전 7:34

아까는 접속할 수 없었는데, 이제는 WordPress 링크에 접속할 수 있습니다.

gammafunk — 오늘 오전 7:34

json도 업데이트해야 합니다.

ASCIIPhilia — 오늘 오전 7:35

제가 잘못 알았을 수도 있습니다.

gammafunk — 오늘 오전 7:35

이 호스트명이 오타이긴 한데, 중요할지는 모르겠습니다.

어쨌든, 그 페이지의 링크를 https://crawl.akrasiac.org:8443/' target="_blank">https://crawl.akrasiac.org:8443/로 업데이트했습니다. 감사합니다.

그리고 우리의 서버 json도 업데이트하겠습니다. CAO에 대한 정보도 구식이니까요.

ASCIIPhilia — 오늘 오전 7:50

```

[CDI]

'wss://crawl.dcss.io/socket'

'https://crawl.dcss.io/crawl/rcfiles/crawl-git/%n.rc'

[CDO]

콘솔 전용

'https://crawl.develz.org/configs/trunk/%n.rc'

[CAO]

'wss://crawl.akrasiac.org:8443/socket'

'https://crawl.akrasiac.org/rcfiles/crawl-git/%n.rc'

[CUE]

'wss://underhound.eu:8080/socket'

'https://underhound.eu/crawl/rcfiles/crawl-git/%n.rc'

[CBRO2]

'wss://cbro.berotato.org:8443/socket'

'https://cbro.berotato.org/rcfiles/crawl-git/%n'

[LLD]

'ws://lazy-life.ddo.jp:8080/socket'

'http://lazy-life.ddo.jp:8000/' (작동하지 않음)

'http://lazy-life.ddo.jp:8080/rcfiles/trunk/%n.rc' (작동하지 않음)

[CWZ]

서버 다운

[CXC]

'wss://crawl.xtahua.com/socket'

'https://crawl.xtahua.com/crawl/rcfiles/crawl-git/%n.rc'

[CPO]

'wss://crawl.project357.org/socket'

'https://crawl.project357.org/rc-files/trunk/%n.rc'

```

PleasingFungus — 오늘 오전 7:51

이 아이디어는 멋지지만, 기존 DB로 시작하는 것보다 낫다고 확신하기 어렵습니다.

다중 소유권 주장이 있는 계정...

솔직히 말해서, 이런 문제에 대해 걱정해야 하는지 잘 모르겠습니다. 실제로 그런 문제를 겪은 기억이 없습니다.

그리고 이런 사용자는 매우 드물기 때문에, 이 방법은 초기 기간이 끝난 후 그리핑 가능성을 허용하는 면에서 더 나쁩니다 - gammafunk가 언급한 것처럼.

이 시스템을 무기한으로 유지한다면 이 방법도 괜찮겠지만, 유지보수에는 당연히 작업이 필요합니다.

제 직감으로는, 서버 관리자와 사용자 모두에게 기존 DB를 재사용하는 것이 더 적은 작업일 것 같습니다. 하지만 이 방법에 대해 강하게 느낀다면 '인증된 로그인' 시스템을 무기한으로 유지하는 것도 괜찮은 차선책입니다. ?

참고로, 서버를 새로 출시하는 시점에 이렇게 많은 문제를 일으켜서 정말 죄송합니다! 서버 설정 작업을 해주셔서 정말 감사합니다. 단지 과거에 겪었던 '트롤' 문제를 피하고 싶을 뿐입니다.

ASCIIPhilia — 오늘 오전 7:58

저는 반대 질문을 하고 싶습니다: 서버가 오픈된 지 6개월 후에 많은 사람들이 그렇게 하려고 할까요? 제 생각에는, 계정 충돌 사례가 매우 적다는 점을 언급하신 것처럼, 아무도 그 계정을 사용하려고 하지 않을 것 같습니다. (그때쯤이면 잊혀졌을 것입니다.)

PleasingFungus — 오늘 오전 7:59

저는 반대 질문을 하고 싶습니다: 서버가 오픈된 지 6개월 후에 많은 사람들이 그렇게 하려고 할까요?

네.

ASCIIPhilia — 오늘 오전 7:59

괜찮습니다. 완전히 이해합니다. 엄격한 플레이어들은 이 문제에 대해 훨씬 더 민감할 것입니다. 좋은 해결책을 찾기 위해 노력할 가치가 있습니다. ?

PleasingFungus — 오늘 오전 8:00

더 설명하자면: 그런 트롤들은 '활성 연승 목록' 같은 것을 보고, 그 목록에 있는 각 플레이어를 위해 모든 서버를 돌아다니며 그 플레이어가 그 서버에 등록하지 않았는지 확인합니다.

서버가 얼마나 오래 열려 있었는지는 중요하지 않습니다. 오래된 플레이어가 단순히 한 서버를 간과했을 가능성이 항상 있기 때문에, 트롤들은 모든 서버를 확인할 것입니다.

ASCIIPhilia — 오늘 오전 8:01

정말 화가 날 정도로 교묘하네요. 그런 사람들이 있다는 것이 놀랍습니다.

이를 보니 근본적으로 통합된 계정 관리 시스템을 만드는 것이 올바른 접근법일 것 같습니다.

PleasingFungus — 오늘 오전 8:02

네, 맞습니다.

우리는 여러 해 동안 그런 시스템을 원해왔습니다...

하지만 그것은 많은 작업이 필요하고, 다중 계정을 가진 드문 사용자들이 이런 문제를 일으킬 것입니다. 그들에 대해 어떤 조치를 취해야 하기 때문입니다.

아마도 이런 식으로 할 수 있을 것 같습니다...

중앙 서비스에서 새로운 등록 및 로그인을 설정하고

기존 서버에서는 등록을 중단하지만 기존 계정을 계속 사용할 수 있도록 하는 것

그러나 큰 질문들이 생깁니다:

중앙 서비스에서 이미 서버에 존재하는 계정을 등록할 때 무슨 일이 일어날까요? 다른 자격 증명으로도 로그인할 수 있을까요? 이는 큰 그리핑 기회가 아닐까요..?

ASCIIPhilia — 오늘 오전 8:09

하지만 한 번 과정을 거치면 그 이후에는 걱정할 필요가 없을 것입니다. 어쨌든, 이는 쉬운 일이 아닙니다.

ASCIIPhilia — 오늘 오전 8:17

이 시스템을 최대 1년 동안 사용할 수 있다고 생각합니다. 무기한 사용하면 다른 서버 데이터베이스에 의존하게 되어, 다른 서버 데이터베이스로 시작하는 것과 거의 동일한 상황이 됩니다.

PleasingFugus의 우려를 이해하지만, 여전히 약 1년의 기간이 충분하다고 생각합니다. 다른 의견이 있습니까?

처음부터 특정 서버의 데이터베이스를 사용하는 것이 모든 그리핑으로부터 자유로운 것은 아닙니다.

이는 선택의 문제인 것 같습니다:

1. 특정 서버의 데이터베이스 사용자는 자동 등록 혜택을 받고 대부분의 그리핑을 방지합니다.

2. 특별한 기록을 가진 몇몇 사람들을 제외하고는 모든 사람에게 동등한 등록 기회를 제공하며, 여전히 대부분의 그리핑을 방지합니다.

gammafunk — 오늘 오전 8:44

특히 비미국 사용자들에게는 특정 서버 데이터베이스를 사용할 수밖에 없기 때문에 장점이 있다고 생각합니다.

DB 가져오기 접근 방식은 유럽이나 CPO 사용자들에게는 ASCIIPhilia의 시스템만큼 공정하지 않습니다.

LLD에 있는 소수의 사용자에게도 비슷한 문제가 있을 것입니다. CPO나 LLD에 많은 사용자가 있지는 않지만, 두 서버 모두 한국 서버를 사용했을 가능성이 있습니다.

기술적인 구현 세부 사항과 실제 사용에서 예기치 않은 문제가 발생할까 걱정이 됩니다. 하지만 기본적으로 WebSocket을 통해 인증하고 rc 파일 URL을 확인하는 것은 그리 어렵지 않습니다.

PleasingFungus — 오늘 오전 8:48

처음부터 특정 서버의 데이터베이스를 사용하는 것이 모든 그리핑으로부터 자유로운 것은 아닙니다.

네, 새로운 그리핑 기회가 되지 않는다는 것을 의미합니다. 기존 DB를 사용하면 현재 상태와 비교해 나빠지지 않습니다. 우리가 복사하는 DB에 계정을 등록하지 않은 경우, 트롤들은 이미 그들에게 문제를 일으킬 수 있습니다.

이 시스템을 최대 1년 동안 사용할 수 있다고 생각합니다. 무기한 사용하면 다른 서버 데이터베이스에 의존하게 되어, 다른 서버 데이터베이스로 시작하는 것과 거의 동일한 상황이 됩니다.

이 부분을 이해하지 못했습니다. 다시 설명해 주실 수 있나요?

ASCIIPhilia — 오늘 오전 8:50

다른 서버의 정보를 사용하여 등록을 유지하는 시스템을 유지하는 것은 처음부터 다른 서버의 데이터베이스로 시작하는 것과 다르지 않다는 의미입니다.

gammafunk — 오늘 오전 8:51

한 가지 중요한 차이점이 있습니다: 이것은 하나의 서버 데이터베이스가 아닌 모든 서버 데이터베이스로 시작하는 것과 동일합니다.

PleasingFungus — 오늘 오전 8:51

특별한 기록을 가진 몇몇 사람들을 제외하고는 모든 사람에게 동등한 등록 기회를 제공하며, 여전히 대부분의 그리핑을 방지합니다.

두 가지 요점:

당신의 제안은 '1년 동안 DCSS를 잊은' 사람들뿐만 아니라, DCSS를 계속 플레이하지만 새로운 서버 공지를 보지 못했거나 (또는 봤지만 잊어버렸거나, 그 중요성을 깨닫지 못한) 사람들에게도 영향을 미칩니다.

또한, 공지를 본 사람들에게도 계정을 등록하는 데 추가 작업이 필요합니다. 이는 많은 플레이어가 기존 DB를 가져올 경우 하지 않아도 될 작업입니다. 각 플레이어에게는 작은 작업이지만, 많은 플레이어에게는...

ASCIIPhilia — 오늘 오전 8:52

이 부분을 이해하지 못했습니다. 다시 설명해 주실 수 있나요?

ㄴ 저는 영작 능력이 좋지 않아서 도구에 의존합니다. 이런 것은 얼마든지 요청해 주세요. ?

PleasingFungus — 오늘 오전 8:52

다른 서버의 정보를 사용하여 등록을 유지하는 시스템을 유지하는 것은 처음부터 다른 서버의 데이터베이스로 시작하는 것과 다르지 않다는 의미입니다.

설명해 주셔서 감사합니다!

gammafunk가 말한 것 외에도, 귀하의 접근 방식은 우리가 데이터베이스를 전송하지 않는다는 것을 의미합니다. 이는 몇 가지 보안상의 이점이 있습니다.

그러나 방금 생각난 또 다른 문제는...

...귀하의 시스템은 누군가가 계정을 등록하려고 할 때마다 비밀번호를 모든 다른 서버에 평문으로 보내야 한다는 의미가 아닙니까? 그것은 조금 불편합니다...

gammafunk — 오늘 오전 8:53

아니요

TLS 웹소켓을 사용할 것입니다.

물론 TLS를 지원하는 서버의 경우입니다.

PleasingFungus — 오늘 오전 8:54

물론, 하지만 서버는 평문으로 받겠죠, 그렇죠?

그래서 만약 우리의 서버 중 하나가 어떤 식으로든 손상된다면, 우리는 많은 추가 비밀번호를 보내게 될 것입니다. 물론 사람들이 직접 사용한 비밀번호도 포함해서요...

아마도 그런 경우에는 더 큰 문제가 있겠지만, 조금 유감스럽네요.

gammafunk — 오늘 오전 8:55

맞아요, 보안 관점에서 보면 이상적인 시스템 설계는 아닙니다.

ASCIIPhilia — 오늘 오전 8:57

하지만 이 시스템을 일시적으로 운영한다면 큰 문제가 되지 않을 수 있습니다.

제가 확인한 바로는 LLD만이 TLS 없이 웹소켓을 사용하고 있습니다.

게다가 이미 LLD에서 RC 파일을 가져오는 것이 불가능하기 때문에, 이 서버는 어차피 확인에서 제외되었을 가능성이 큽니다.

PleasingFungus — 오늘 오전 8:59

비밀번호 전송 문제는 제 가장 큰 걱정이 아닙니다. 다른 문제들이 더 중요하다고 생각합니다. ?

ASCIIPhilia — 오늘 오전 9:11

반대로, 귀하의 제안의 사각지대에 해당하는 사람들은 그들이 잃지 말아야 할 등록 기회를 박탈당할 수도 있습니다.

PleasingFungus — 오늘 오전 9:12

그런 사람들은 드물거나 존재하지 않는 것 같습니다.

ASCIIPhilia — 오늘 오전 9:13

트롤에 의해 연승이 깨질 사람도 1년 후에는 드물 것이라고 생각합니다.

PleasingFungus — 오늘 오전 9:13

저는 그렇지 않다고 생각합니다. 위에서 설명한 이유들 때문입니다.

그리고 그들에게 불편을 주는 것은 매우 미미합니다. 그들은 등록 기회를 박탈당하지 않습니다. 단지 다른 계정 이름을 선택해야 할 것입니다. 인터넷에서 누구나 익숙한 일입니다.

당신은 여러 번 '공정성'에 대해 이야기했지만, 왜 그런지 이해하지 못하겠습니다.

여기에는 '정의'나 '공정성' 문제는 없습니다.

서버에서 계정 이름을 등록할 권리가 본질적으로 있는 것은 아닙니다.

저는 매우 혼란스럽습니다!

ASCIIPhilia — 오늘 오전 9:14

왜 그것이 권리가 아니죠? 많은 온라인 게임들은 닉네임을 위한 사전 등록 기간을 운영합니다.

PleasingFungus — 오늘 오전 9:14

왜 그것이 권리여야 하죠? 누가 그것을 권리로 정했습니까?

당신이 원한다면 그것을 권리로 선언할 수 있습니다. 당신은 서버 관리자입니다.

하지만 그것은 인권이 아닙니다. 신이나 헌법에 의해 부여된 권리가 아닙니다.

이름에 대한 "선착순"은 흔한 관행이지만, 권리는 아닙니다.

다른 문제가 없다면 합리적인 기본값입니다. 그러나 저는 여기서 다른 문제들을 이미 설명했습니다.

그것이 왜 중요한지 정말 이해하지 못하겠습니다.

ASCIIPhilia — 오늘 오전 9:21

처음부터 계정 데이터베이스가 통합되어 이 시스템이 유지되었다면, 그런 사용자를 보호하는 것은 당연했을 것입니다. 그러나 이미 여러 번 이 무결성이 선의든 트롤이든 깨진 사례가 많았습니다.

저는 그런 사용자를 완전히 무시하는 것이 아니라, 그들에게 1년의 기간을 제공하려고 제안하고 있습니다.

CWZ에서 게임을 할 때, 게임 내 신들의 이름을 사용자 이름으로 사용한 플레이어들이 있었습니다. 이들은 다른 서버에서 이미 사용 중인 이름이어서 등록할 수 없었지만, CWZ에서는 행복하게 플레이했고 다른 서버의 기록과 섞이는 것을 신경 쓰지 않았습니다.

PleasingFungus — 오늘 오전 9:22

구체적인 예를 제공해주셔서 감사합니다! 도움이 됩니다.

그런 사용자를 특별히 처리하는 아이디어는 어떨까요? 다른 서버에서 데이터베이스를 가져온 다음, 그 사용자들을 삭제하여 CWZ에서 사용한 이름으로 등록할 수 있도록 하는 것이 실용적일까요?

ASCIIPhilia — 오늘 오전 9:27

일부 부분을 이해하지 못했습니다. 어떻게 그런 사용자를 식별하고 특별히 처리할 수 있나요?

그리고 왜 삭제해야 하죠?

DB를 사용하는 것과 그런 사용자를 고려하는 것을 결합하는 절충안을 제안하는 것인가요? 그들은 자연스럽게 ID를 얻고 사용했습니다. 게다가 제 서버는 CWZ가 아니므로 왜 그들을 특별히 고려해야 하나요? 이것이 제가 말하는 공정성입니다.

gammafunk — 오늘 오전 9:41

ASCIIPhilia가 말한 게임 내 신들의 이름을 사용하는 사용자 예시는 단지 모든 사람들이 다른 서버의 계정 이름 등록 결과(및 그에 따른 공유 점수의 영향)를 수용해야 한다는 것을 설명하기 위한 것입니다. 특정 사용자를 특별히 돕고자 하는 예시는 아닙니다.

그게 도움이 된다면요.

ASCIIPhilia — 오늘 오전 9:42

네, 맞습니다.

ASCIIPhilia — 오늘 오전 9:50

'권리'라는 단어가 제 모국어의 비슷한 단어와 약간 다른 뉘앙스를 가질 수 있습니다(권리를 의미하는 단어). 저는 그것을 인권이 아닌 서비스 사용자가 자연스럽게 할 수 있어야 하는 것으로 의미했습니다.

PleasingFungus — 오늘 오전 10:33

오, 실제 플레이어인가요, 아니면 가상의 사례인가요?

저는 실제 플레이어에만 관심이 있습니다.

얘기할수록 이 공정성 개념을 이해하기 어려워집니다. 새로운 서버에 처음 접속한 사람이 해당 사용자 이름을 얻는 것이 왜 몇 년 동안 다른 서버에서 그 이름을 사용해 온 사람보다 더 공정한가요?

왜 첫 번째는 "서비스 사용자가 자연스럽게 할 수 있어야 하는 것"인데 두 번째는 그렇지 않은가요?

이 문제를 논의하는 동안 인내심을 가져주셔서 감사합니다... 더 명확하게 소통하지 못해 죄송합니다.

ASCIIPhilia — 오늘 오전 11:35

아니요, 저도 제 뜻을 명확하게 전달하지 못해 죄송합니다. 이 주제에 대해 제 의견에 인내심을 가져주셔서 감사합니다.

웹타일 서버에 대해 이야기할 때 누가 서버의 소유자인지 물으면, 보통 그 서버의 관리자를 지칭합니다. 그러나 점수판 시스템은 조금 더 복잡합니다. 간단히 말해, 그것은 우리 모두의 것이라고 말할 수 있습니다.

기본적으로, 제가 소유한 서버를 다른 사람이 소유한 서버의 데이터베이스와 동기화해야 할 이유는 없습니다. 서버가 점수판 시스템과 통합되지 않을 경우, 더욱 그럴 이유가 없습니다.

다른 서버의 사용자를 제 3자라고 생각하면 쉽게 이해할 수 있습니다.

제가 말하는 것은 주로 제 서버 사용자에 대한 공정성입니다. 다른 서버의 사용자들(제 3자)은 여기서 간섭해서는 안 됩니다. 따라서 "다른 서버의 사용자들이 새 서버에서 자동으로 이름을 얻는 것(두 번째 경우)"은 자연스럽지 않습니다. 그러나 이 동기화와 그 부작용을 고려하는 것은 점수판 시스템에 대한 "존중"의 문제입니다. 그 존중의 절충안으로 1년의 기간을 제안하고 있습니다.

모든 공식 서버가 자율성이 없고 점수판 시스템에 종속된다고 주장한다면, 저는 그 조치를 이해할 수 있습니다.

ASCIIPhilia — 오늘 오전 11:48

또한, 공식 서버의 자율성이 부족하다는 것이 나쁘다고 말하는 것은 아니며(그것도 의미가 있습니다), 제 접근 방식을 반드시 따르라고 생각하지도 않습니다.

이 주제에 대해 다양한 사람들의 생각을 듣고 싶습니다.

PleasingFungus — 오늘 오전 11:51

설명해주셔서 감사합니다!

한 가지 요점은, 당신의 서버 사용자들만의 관점에서도 데이터베이스를 가져오는 것이 많은 사용자들에게 도움이 된다는 것입니다. 많은 사용자가 이미 다른 서버에 계정을 가지고 있기 때문에, 재등록할 필요가 없어 시간을 절약할 수 있습니다.

ASCIIPhilia — 오늘 오전 11:54

네, 각 접근 방식에는 분명 장단점이 있습니다.

PleasingFungus — 오늘 오전 11:54

다른 서버에서 누군가가 이름을 사용한 경우, 기존 DB를 가져오는 것이 분명 더 나쁩니다. 하지만 그런 사람들이 적을 것 같고, 이메일이나 디스코드를 통해 "항소 절차"를 마련할 수 있을 것 같습니다. 이 부분에 대해 더 이야기할 수 있습니다.

또한...

모든 공식 서버가 자율성이 없고 점수판 시스템에 종속된다고 주장한다면, 저는 그 조치를 이해할 수 있습니다.

이것은 흥미로운 질문입니다. '공식' 서버가 된다는 것은 주로 점수판 시스템에 포함된다는 것을 의미합니다. 따라서 우리는 공식 서버가 기존 사용자에게 점수판을 '깨지 않게' 하기를 원합니다.

반면, 이 모든 것은 단지 게임일 뿐이고, 서버를 운영하는 모든 사람들은 재미로 하고 있습니다. 따라서 어느 정도의 유연성과 절충이 필요합니다.

제 걱정은 '1년' 제안이 많은 사람들(당신과 플레이어 모두)에게 많은 추가 작업을 만들고, 그 1년이 끝나면 문제를 초래할 수 있다는 것입니다.

제가 틀렸고 모든 것이 괜찮을 것이라고 믿을 수 있습니다. 아마도 1년이 충분할 것입니다.

하지만 쉽게 피할 수 있는 잠재적인 문제를 만드는 것은 아쉽습니다.

서버의 플레이어가 '오래된 계정'을 가진 사용자보다 더 중요하다는 점에는 동의합니다. 하지만 제 직감 - 틀렸다면 정정해 주세요! - 은 '다른 사람과 닉네임을 공유한 CWZ 사용자가 거의 없다'는 것입니다. 만약 그런 사람들이 매우 적다면, 당신의 서버 사용자의 관점에서도 DB를 가져오는 것이 더 나을 것 같습니다.

PleasingFungus — 오늘 오후 12:01

그리고 그 몇몇 사용자는 어떤 식으로든 수작업으로 처리할 수 있습니다, 항소를 통해서든.

'1년' 접근 방식이 최선의 방법이라고 진정으로 느낀다면, 이를 반대하지는 않겠습니다. 하지만 제 생각도 고려해 주시기 바랍니다.

ASCIIPhilia — 오늘 오후 12:08

이 대화를 번역해서 CWZ와 긴밀히 소통해온 커뮤니티(향후 제 서버의 주요 활성 사용자가 모일 가능성이 높은 곳)에 게시해도 괜찮을까요? 여러 사람의 의견을 듣고 싶습니다.

어떤 서버의 데이터베이스를 기준으로 사용할 수 있나요?

그리고 이 문제에 대한 최종 결정권자는 누구인가요? 여기 있는 모든 사람이 동의해야 하나요? 아니면 궁극적으로 제가 결정하는 것인가요?

ebering — 오늘 오후 12:12

@advil과 제가 알기로는 @gammafunk이 CAO 점수에 접근할 수 있습니다. 이와 관련된 공식적인 규칙은 없습니다.

PleasingFungus — 오늘 오후 12:27

이 대화를 번역해서 CWZ와 긴밀히 소통해온 커뮤니티(향후 제 서버의 주요 활성 사용자가 모일 가능성이 높은 곳)에 게시해도 괜찮을까요? 여러 사람의 의견을 듣고 싶습니다.

ㄴ 물론입니다! 그게 말이 되네요. 도움이 필요하면 알려주세요.

PleasingFungus — 오늘 오후 12:28

어떤 서버의 데이터베이스를 기준으로 사용할 수 있나요?

ㄴ gammafunk이 CDI를 사용하는 것이 합리적이라고 제안했습니다: ⁠admin-private⁠