Ники и конфликты

У каждого аккаунта один ник, и он следует за провайдером аккаунта: аккаунт Premium играет под своим ником Mojang, аккаунт Credential — под ником, с которым игрок зарегистрировался.

Провайдеры, которые владеют никамиСкопировать ссылку на раздел

Некоторые провайдеры гарантируют, что каждый ник принадлежит одному из их игроков, и проверяют, что игрок, который заходит под этим ником, действительно им владеет. Premium так делает: только владелец аккаунта Mojang Steve может зайти через Premium как Steve. Credential — нет, потому что его игроки выбирают ники сами.

В конфигурации эта гарантия называется OWNED_USERNAME. Она — часть того, что представляет собой провайдер, и включить её в файле нельзя. Правила ниже опираются на неё, чтобы решить, кто сохранит ник.

Уникальные никиСкопировать ссылку на раздел

Ники уникальны без учёта регистра, как ники Minecraft: пока аккаунт владеет ником Alice, никакой другой аккаунт не получит alice или ALICE. Когда игрок хочет ник, которым владеет другой аккаунт, решают правила конфликтов. Ни один исход не пускает игрока в чужой аккаунт: правило решает только, какой из двух аккаунтов сохранит ник, а какой будет переименован, или отказывает входящему игроку.

Когда возникает конфликтСкопировать ссылку на раздел

Игрок хочет ник в двух ситуациях:

• Первый вход (FIRST_JOIN): игрок впервые заходит через провайдера и хочет его ник. Это новый аккаунт, а также аккаунт, который переходит к другому провайдеру, например командой /premium, и с этого момента берёт ник у него.
• Смена ника у провайдера (PROVIDER_RENAME): провайдер известного аккаунта даёт ему новый ник, например после смены ника в Mojang.

Если нужным ником никто не владеет, аккаунт его получает. Если ником владеет другой аккаунт, конфликт решают правила. Заходящий игрок — это входящая сторона; аккаунт, который владеет ником, — держатель.

Конфликт решается до того, как прокси назовёт игрока, поэтому переименованный игрок сразу играет под новым ником, а игрок, которому отказали, получает отказ раньше любого запроса. Так бывает, когда провайдер известен уже при входе: по ожидающей миграции, привязанному аккаунту, имени хоста провайдера или подтверждённому входу. Если провайдер только угадан — по аккаунту с тем же ником или по тому, что провайдер нашёл для этого ника, — игрок ещё может выбрать другой провайдер, поэтому конфликт решается, когда он его выбрал.

Правила по умолчаниюСкопировать ссылку на раздел

Например, игрок Credential зарегистрировал ник Steve. Когда владелец лицензионного аккаунта Steve впервые заходит через Premium, он получает Steve, а аккаунт Credential становится Steve_credential. Игрок Credential по-прежнему входит с тем же ником в клиенте и тем же паролем и с этого момента играет как Steve_credential.

Лицензионный игрок, который заходит через имя хоста провайдера Premium, попадает под первое правило. Лицензионного игрока, который заходит без него, может отправить к запросу пароля аккаунта Credential, потому что ник совпадает с этим аккаунтом; см. Как выбирается провайдер.

Правила по умолчанию называют только гарантии, а не провайдеров, поэтому охватывают и провайдеров, добавленных позже.

Изменение правилСкопировать ссылку на раздел

Правила находятся в identity/username/conflicts.yml. Каждое правило называет, что оно требует от входящего игрока и от держателя, и исход. Несколько частых изменений:

Отключать держателя в сети, а не оставлять его играть под прежним ником, пока он не выйдет:

outcomes:
  rename-holder:
    holderOnline: KICK_HOLDER

Переименовывать аккаунты Credential иначе, чем все остальные:

providers:
  credential:
    rename-holder:
      pattern: "{username}_offline"

Отказывать вместо переименования для одной пары провайдеров — добавьте правило, которое их называет. Правило с провайдерами конкретнее правил по умолчанию и побеждает их:

rules:
  - arriving: { providers: [premium] }
    holder: { providers: [credential] }
    outcome: refuse

В разделе identity/username описаны все поля, какое правило побеждает, когда подходят несколько, и как составляются новые ники.

Правила, которые не меняютсяСкопировать ссылку на раздел

• Ни один исход не пускает игрока в чужой аккаунт.
• Ник, назначенный администратором вручную, Identica никогда не меняет. Если правило переименовало бы такого держателя, вместо него переименовывается входящий аккаунт.
• Аккаунт, переименованный в конфликте, при следующем входе забирает свой ник обратно, как только им никто не владеет.

Переименование аккаунта вручнуюСкопировать ссылку на раздел

/identica admin username rename <account> <username> переименовывает аккаунт, указанный ником или UUID. Новый ник должен состоять из 3–16 букв, цифр или _, и никто не должен владеть им ни в каком регистре. Identica сохраняет такой ник: его не меняет ни конфликт, ни смена ника у провайдера. Игрок играет под ним со следующего входа.

Аккаунты с общим никомСкопировать ссылку на раздел

В базе данных из времён, когда ники ещё не были уникальными, несколько аккаунтов могут делить один ник. При обновлении базы ник остаётся за самым старым аккаунтом; остальные по-прежнему входят через собственных провайдеров, но держателями ника не считаются. При каждом запуске консоль предупреждает о каждом нике, который делят несколько аккаунтов, и называет эти аккаунты с их UUID, провайдерами и временем последнего входа:

Duplicate usernames: steve is shared by steve (…, providers credential, last seen …), Steve (…, providers premium, last seen …). …

/identica admin username duplicates выводит те же аккаунты. Чтобы оставить ник одному аккаунту, переименуйте остальные вручную.

СообщенияСкопировать ссылку на раздел

identity/username/messages.yml содержит то, что видят игроки: