Безопасно ли превращать UUID в короткий код?(используйте только первые 8 символов)

Question

Мы используем UUID для наших первичных ключей в нашей базе данных (генерируется php, хранится в mysql). Проблема в том, что когда кто-то хочет что-то отредактировать или просмотреть свой профиль, в конце URL-адреса появляется эта огромная, страшная и уродливая строка uuid. (Изменить? ID = .....)

Было бы безопасно (читай: все еще уникально), если бы мы использовали только первые 8 символов, все до первого дефиса?

Если это НЕ безопасно, есть ли какой-нибудь способ перевести его во что-то более короткое для использования в URL, которое можно перевести обратно в гекс для использования в качестве поиска? Я знаю, что могу закодировать его в base64, чтобы уменьшить его до 22 символов, но есть ли что-то еще короче?

EDIT Я прочитал этот вопрос и он сказал использовать base64. опять что нибудь короче?

Answer 1

Не вырезайте ни единого бита из этого UUID: у вас нет контроля над алгоритмом, который его создал, есть несколько возможных реализаций, реализация алгоритма может быть изменена (пример: изменилось с версией PHP, в которой вы работаете) используя)

Если вы спросите меня, UUID в адресной строке не выглядит пугающим или сложным, даже простой поиск в Google "UUID" приводит к худшим URL-адресам, и все привыкли смотреть на Google-URL!

Если вы хотите, чтобы URL выглядели лучше, посмотрите на адресную строку этой статьи на stackoverflow.com. Они используют идентификатор статьи, за которым следует заголовок вопроса. Уместна только часть идентификатора, все остальное есть, чтобы облегчить глаза читателей (попробуйте и попробуйте, вы можете удалить что-нибудь после идентификатора, вы можете заменить его на мусор - не имеет значения).

Answer 2

Сокращение UUID увеличивает вероятность столкновения.Вы можете сделать это, но это плохая идея.Использование только 8 символов означает только 4 байта данных, поэтому вы можете ожидать коллизию, когда у вас будет около 2 ^ 16 идентификаторов - далеко не идеально.не шестнадцатеричное представление) и закодируйте его с помощью base64.Или просто не беспокойтесь, потому что я серьезно сомневаюсь, что ваши пользователи заботятся о том, что в URL.

Answer 3

Обрезать uuid небезопасно. Кроме того, они разработаны, чтобы быть глобально уникальными, так что вам не повезет, сокращая их. Лучше всего либо назначить каждому пользователю уникальный номер, либо позволить пользователям выбрать пользовательскую (уникальную) строку (например, имя пользователя или псевдоним), которую можно декодировать. Таким образом, вы можете отредактировать? Id = .... или edit? Name = blah и затем декодировать имя в uuid в вашем скрипте.

Answer 4

Если вы беспокоитесь о том, чтобы напугать пользователей UUID в URL, почему бы не записать его в скрытое поле формы?

Answer 5

Это зависит от того, как вы генерируете UUID - если вы используете PHP uniqid , то самые правые цифры являются более «уникальными». Однако, если вы собираетесь урезать данные, то нет никакой реальной гарантии, что они все равно будут уникальными.

Независимо от того, я бы сказал, что это несколько неоптимальный подход - нет ли способа, которым вы можете использовать уникальную (и идеально значимую) текстовую ссылочную строку вместо идентификатора в строке запроса? (Трудно понять, не зная проблемной области, но, на мой взгляд, это всегда лучший подход, даже если SEO и т. Д. Не имеют значения.)

Если бы вы использовали этот подход, вы также могли бы позволить MySQL генерировать уникальные идентификаторы, что, вероятно, является гораздо более разумным подходом, чем попытка обработать это в PHP.