как узнать uuid игрока
BBya World
Меню навигации
Пользовательские ссылки
Объявление
Информация о пользователе
Вы здесь » BBya World » F.A.Q. / ЧаВо » Как узнать UUID игрока?
Как узнать UUID игрока?
Сообщений 1 страница 4 из 4
Поделиться121-07-2014 19:14:04
Итак, что такое этот UUID и с чем его едят?
небольшой ликбез | удобный поиск UUID
На что стоит обратить внимание:
— теперь профили игроков (файлы на сервере) называются не ником игрока, а его UUID, но суть их от этого не изменилась (их также можно переименовывать);
— основные трудности будут первое время только с плагинами, стандартные внутриигровые инструменты (баны по нику, вайт-лист) оптимизированы для автоматического перехода на UUID;
— пока остаётся открытым вопрос с использованием ников в командных блоках и при добавлении в команды;
+ миграция на аккаунт Mojang необходима, если Вы хотите сменить свое имя;
+ имя должно быть уникально, Вы не сможете выбрать имя, которое уже занято;
+ если Вы сменили имя, то Ваше имя будет доступно для «захвата», это не традиционные «локальные» имена, это глобальная система имён.
Итак, оставшиеся вопросы:
— как правильно работать с командными блоками при указании ника игрока и как будет вести себя игра, обрабатывая такие условия (возможно, придётся полностью переходить на работу с переменными)?
— как будут обрабатываться команды, в которых находятся игроки, если игрок меняет имя?
+ если имена можно будет «терять и захватывать», то как это будет отрабатываться на забаненных и снова в тех же командах и командных блоках??
Universally unique identifier
UUIDs (Universally unique identifiers; Java Class) are 128 bit long numbers that are used by Minecraft to distinguish between separate instances.
Contents
Representation [ ]
Occurences [ ]
The following table represents the situations in which UUIDs are used in places accessible by a player:
Location (general) | Location (path) | Format | Use |
---|---|---|---|
All entities (NBT) | UUID | int-array | Own UUID |
Attribute modifiers (NBT) | UUID | int-array | Own UUID. Used when equipping and unequipping the item to identify which modifier to add or remove from the entity. |
Attribute modifiers (Loot table) | id | Hyphenated hexadecimal | Set UUID of modifier in set_attributes function |
/attribute | — | Hyphenated hexadecimal | Used to identify modifier |
Tameable mobs (NBT) | Owner | int-array | Owner |
Projectiles (NBT) | Owner | int-array | Entity that shot the projectile |
Item entities (NBT) | Owner | int-array | Target player for /give command |
Item entities (NBT) | Thrower | int-array | Player who dropped the item |
Shulker bullets (NBT) | Target | int-array | Entity targeted for attack |
Conduits (NBT) | Target | int-array | Entity targeted for attack |
Player heads (NBT) | SkullOwner.Id | int-array | Owner of the skin |
Player heads (NBT) | SkullOwner.Properties.textures[].Value.ProfileId | hexadecimal | Owner of the skin |
Mobs (NBT) | Leash.UUID | int-array | Entity that leashed the mob |
Breedable mobs (NBT) | LoveCause | int-array | Player who fed the mob |
Zombie Villagers (NBT) | ConversionPlayer | int-array | Player who is converting the Zombie Villager |
Neutral mobs except piglins (NBT) | AngryAt | int-array | Entity that hurt the neutral mob |
Villagers (NBT) | Gossips[].Target | int-array | Player who caused the gossip |
Players (NBT) | RootVehicle.Attach | int-array | Identifier of the entity that the player is riding |
Target selectors (Commands) | — | Hyphenated hexadecimal | Selected entity |
Technical aspects [ ]
Value range [ ]
Hyphenated hexadecimal format section names [ ]
Section name | Bit range | |||
---|---|---|---|---|
From | To | Size | Characters | |
time-low | 96 | 127 | 32 | 8 |
time-mid | 80 | 95 | 16 | 4 |
time-high-and-version | 54 | 79 | 16 | 4 |
clock-seq-and-reserved | 36 | 53 | 8 | 2 |
clock-seq-low | 48 | 45 | 8 | 2 |
node | 0 | 47 | 48 | 12 |
(The names make sense only for version 1 and 2 UUIDs, but it has been passed onto all forms of UUIDs used.)
Versions and variants [ ]
There have been five versions of UUIDs. Versions 1 and 2 are based on current time and MAC address; versions 3 and 5 are based on hashing a string; version 4 is based on completely random generation. The «version» value occupies four bits, and is located in the UUID string format at the position indicated by an «A».
The «B» position is the variant (format) of the UUID. Depending on the specific variant, it may occupy the high 1 to 3 bits:
In Minecraft [ ]
Minecraft uses version 4, variant 1 (RFC) UUIDs, which means that the entire number with the exception of the bits used for metadata (version and variant) is randomly generated. Java’s UUID.randomUUID() function performs this exact task.
A table with the locations and values of the metadata:
📑 Команда id — найти UID пользователя или GID
Эта команда полезна для поиска следующей информации:
Цель
Отображает системные идентификаторы указанного пользователя.
синтаксис команды id
По умолчанию команда id показывает имена пользователей и групп и числовые идентификаторы вызывающего процесса, то есть текущего пользователя, который запускает команду id на экране. Если имя пользователя или идентификатор пользователя ([UserNameHere]) указаны в командной строке, отображаются идентификаторы пользователя и группы этого пользователя.
Показать свой собственный UID и GID
Как найти UID конкретного пользователя?
В этом примере найдите UID пользователя vasia, введите:
Как найти GID конкретного пользователя?
В этом примере найдите GID пользователя vasia, запустите:
Как увидеть UID и все группы, связанные с именем пользователя?
В этом примере найдите UID и все группы, связанные с пользователем с именем «root», введите:
Как узнать все группы, к которым принадлежит пользователь…
В этом примере отобразите UID и все группы, связанные (вторичные группы) с пользователем с именем «vasia», запустите:
1000 20 12 61 79 80 81 98 33 100 204 398 399
Отображать имя вместо UID / GID
Как отобразить реальный идентификатор вместо эффективного идентификатора для указанного пользователя?
Параметры команды id
Смотрите также
man id — Страница руководства по команде id
Как генерируются UUID
Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует мизерная возможность возникновения одинаковых значений.
Современную реализацию UUID можно проследить до RFC 4122, в котором описано пять разных подходов к генерированию этих идентификаторов. Мы рассмотрим каждый из них и пройдёмся по реализации версии 1 и версии 4.
Теория
UUID (universally unique IDentifier) — это 128-битное число, которое в разработке ПО используется в качестве уникального идентификатора элементов. Его классическое текстовое представление является серией из 32 шестнадцатеричных символов, разделённых дефисами на пять групп по схеме 8-4-4-4-12.
Информация о реализации UUID встроена в эту, казалось бы, случайную последовательность символов:
Значения на позициях M и N определяют соответственно версию и вариант UUID.
Версия
Номер версии определяется четырьмя старшими битами на позиции М. На сегодняшний день существуют такие версии:
Вариант
Это поле определяет шаблон информации, встроенной в UUID. Интерпретация всех остальных битов в UUID зависит от значения варианта.
Мы определяем его по первым 1-3 старшим битам на позиции N.
1 0 0 0 = 8
1 0 0 1 = 9
1 0 1 0 = A
1 0 1 1 = B
Так что если вы видите UUID с такими значениями на позиции N, то это идентификатор в варианте 1.
Версия 1 (время + уникальный или случайный идентификатор хоста)
В этом случае UUID генерируется так: к текущему времени добавляется какое-то идентифицирующее свойство устройства, которое генерирует UUID, чаще всего это MAC-адрес (также известный как ID узла).
Идентификатор получают с помощью конкатенации 48-битного МАС-адреса, 60-битной временной метки, 14-битной «уникализированной» тактовой последовательности, а также 6 битов, зарезервированных под версию и вариант UUID.
Тактовая последовательность — это просто значение, инкрементируемое при каждом изменении часов.
Временная метка, которая используется в этой версии, представляет собой количество 100-наносекундных интервалов с 15 октября 1582 года — даты возникновения григорианского календаря.
Возможно, вы знакомы с принятым в Unix-системах исчислением времени с начала эпохи. Это просто другая разновидность Нулевого дня. В сети есть сервисы, которые помогут вам преобразовать одно временное представление в другое, так что не будем на этом останавливаться.
Хотя эта реализация выглядит достаточно простой и надёжной, однако использование MAC-адреса машины, на которой генерируется идентификатор, не позволяет считать этот метод универсальным. Особенно, когда главным критерием является безопасность. Поэтому в некоторых реализациях вместо идентификатора узла используется 6 случайных байтов, взятых из криптографически защищённого генератора случайных чисел.
Сборка UUID версии 1 происходит так:
Поскольку эта реализация зависит от часов, нам нужно обрабатывать пограничные ситуации. Во-первых, для минимизации коррелирования между системами по умолчанию тактовая последовательность берётся как случайное число — так делается лишь один раз за весь жизненный цикл системы. Это даёт нам дополнительное преимущество: поддержку идентификаторов узлов, которые можно переносить между системами, поскольку начальное значение тактовой последовательности совершенно не зависит от идентификатора узла.
Помните, что главная цель использования тактовой последовательности — внести долю случайности в наше уравнение. Биты тактовой последовательности помогают расширить временную метку и учитывать ситуации, когда несколько UUID генерируются ещё до того, как изменяются процессорные часы. Так мы избегаем создания одинаковых идентификаторов, когда часы переводятся назад (устройство выключено) или меняется идентификатор узла. Если часы переведены назад, или могли быть переведены назад (например, пока система была отключена), и UUID-генератор не может убедиться, что идентификаторы сгенерированы с более поздними временными метками по сравнению с заданным значением часов, тогда нужно изменить тактовую последовательность. Если нам известно её предыдущее значение, его можно просто увеличить; в противном случае его нужно задать случайным образом или с помощью высококачественного ГПСЧ.
Версия 2 (безопасность распределённой вычислительной среды)
Главное отличие этой версии от предыдущей в том, что вместо «случайности» в виде младших битов тактовой последовательности здесь используется идентификатор, характерный для системы. Часто это просто идентификатор текущего пользователя. Версия 2 используется реже, она очень мало отличается от версии 1, так что идём дальше.
Версия 3 (имя + MD5-хэш)
Если нужны уникальные идентификаторы для информации, связанной с именами или наименованием, то для этого обычно используют UUID версии 3 или версии 5.
Они кодируют любые «именуемые» сущности (сайты, DNS, простой текст и т.д.) в UUID-значение. Самое важное — для одного и того же namespace или текста будет сгенерирован такой же UUID.
Обратите внимание, что namespace сам по себе является UUID.
В этой реализации UUID namespace преобразуется в строку байтов, конкатенированных с входным именем, затем хэшируется с помощью MD5, и получается 128 битов для UUID. Затем мы переписываем некоторые биты, чтобы точно воспроизвести информацию о версии и варианте, а остальное оставляем нетронутым.
Важно понимать, что ни namespace, ни входное имя не могут быть вычислены на основе UUID. Это необратимая операция. Единственное исключение — брутфорс, когда одно из значений (namespace или текст) уже известно атакующему.
При одних и тех же входных данных генерируемые UUID версий 3 и 5 будут детерминированными.
Версия 4 (ГПСЧ)
Самая простая реализация.
6 битов зарезервированы под версию и вариант, остаётся ещё 122 бита. В этой версии просто генерируется 128 случайных битов, а потом 6 из них заменяется данными о версии и варианте.
Такие UUID полностью зависят от качества ГПСЧ (генератора псевдослучайных чисел). Если его алгоритм слишком прост, или ему не хватает начальных значений, то вероятность повторения идентификаторов возрастает.
В современных языках чаще всего используются UUID версии 4.
Её реализация достаточно простая:
Версия 5 (имя + SHA-1-хэш)
Единственное отличие от версии 3 в том, что мы используем алгоритм хэширования SHA-1 вместо MD5. Эта версия предпочтительнее третьей (SHA-1 > MD5).
Практика
Одним из важных достоинств UUID является то, что их уникальность не зависит от центрального авторизующего органа или от координации между разными системами. Кто угодно может создать UUID с определённой уверенностью в том, что в обозримом будущем это значение больше никем не будет сгенерировано.
Это позволяет комбинировать в одной БД идентификаторы, созданные разными участниками, или перемещать идентификаторы между базами с ничтожной вероятностью коллизии.
UUID можно использовать в качестве первичных ключей в базах данных, в качестве уникальных имён загружаемых файлов, уникальных имён любых веб-источников. Для их генерирования вам не нужен центральный авторизующий орган. Но это обоюдоострое решение. Из-за отсутствия контролёра невозможно отслеживать сгенерированные UUID.
Есть и ещё несколько недостатков, которые нужно устранить. Неотъемлемая случайность повышает защищённость, однако она усложняет отладку. Кроме того, UUID может быть избыточным в некоторых ситуациях. Скажем, не имеет смысла использовать 128 битов для уникальной идентификации данных, общий размер которых меньше 128 битов.
Уникальность
Может показаться, что если у вас будет достаточно времени, то вы сможете повторить какое-то значение. Особенно в случае с версией 4. Но в реальности это не так. Если бы вы генерировали один миллиард UUID в секунду в течение 100 лет, то вероятность повторения одного из значений была бы около 50 %. Это с учётом того, что ГПСЧ обеспечивает достаточное количество энтропии (истинная случайность), иначе вероятность появления дубля будет выше. Более наглядный пример: если бы вы сгенерировали 10 триллионов UUID, то вероятность появления двух одинаковых значений равна 0,00000006 %.
А в случае с версией 1 часы обнулятся только в 3603 году. Так что если вы не планируете поддерживать работу своего сервиса ещё 1583 года, то вы в безопасности.
Впрочем, вероятность появления дубля остаётся, и в некоторых системах стараются это учитывать. Но в подавляющем большинстве случаев UUID можно считать полностью уникальными. Если вам нужно больше доказательств, вот простая визуализация вероятности коллизии на практике.
BBya World
Меню навигации
Пользовательские ссылки
Объявление
Информация о пользователе
Вы здесь » BBya World » F.A.Q. / ЧаВо » Как узнать UUID игрока?
Как узнать UUID игрока?
Сообщений 1 страница 4 из 4
Поделиться121-07-2014 19:14:04
Итак, что такое этот UUID и с чем его едят?
небольшой ликбез | удобный поиск UUID
На что стоит обратить внимание:
— теперь профили игроков (файлы на сервере) называются не ником игрока, а его UUID, но суть их от этого не изменилась (их также можно переименовывать);
— основные трудности будут первое время только с плагинами, стандартные внутриигровые инструменты (баны по нику, вайт-лист) оптимизированы для автоматического перехода на UUID;
— пока остаётся открытым вопрос с использованием ников в командных блоках и при добавлении в команды;
+ миграция на аккаунт Mojang необходима, если Вы хотите сменить свое имя;
+ имя должно быть уникально, Вы не сможете выбрать имя, которое уже занято;
+ если Вы сменили имя, то Ваше имя будет доступно для «захвата», это не традиционные «локальные» имена, это глобальная система имён.
Итак, оставшиеся вопросы:
— как правильно работать с командными блоками при указании ника игрока и как будет вести себя игра, обрабатывая такие условия (возможно, придётся полностью переходить на работу с переменными)?
— как будут обрабатываться команды, в которых находятся игроки, если игрок меняет имя?
+ если имена можно будет «терять и захватывать», то как это будет отрабатываться на забаненных и снова в тех же командах и командных блоках??