Почему многие сайты (например, youtube) генерируют строку случайных чисел и букв вместо использования, например, идентификатора строки?
обычно ему что-то нравится
bla?v=wli4l73Chc0
а не как
bla?id=83934
Разве это просто, если у вас много строк? Или есть другие хорошие вещи об этом? Потому что я могу себе представить: bla? Id = 23934234234 не выглядите так красиво
Спасибо и приветствуем
На самом деле это не случайные строки. Обычно они являются номерами (обычно строковыми идентификаторами), которые кодируются в кодировке Base-36 (очевидно, это не всегда так, но их много).
Почему они используют его? Потому что закодированная строка Base-36 короче оригинала.
Например: 1234567890 в базе-36 kf12oi, что на 50% короче.
Смотрите статью Википедии . Проверьте раздел "Использование на практике", чтобы узнать, кто его использует.
в распределенной среде проще генерировать случайные числа для идентификаторов, чем порядковые номера.
Я честно не знаю, почему они не будут использовать уникальный идентификатор (или ObjectID или что-то другое в зависимости от какой базы данных), поэтому вы когда-нибудь задумывались, а не представляли ли ID в базе-10, они представляли его в более высокой базе (например, 64 или что-то, что возможно в URL-адресах), чтобы идентификатор был более компактным в строке запроса? (чтение: wli4l73Chc0 - некоторое число в не-base-10)
Я поддержал ответ Роба, но я также немного поразмышляю об одном из рисков.
Если вы публикуете ссылку типа Почему веб-сайты генерируют случайные буквенно-цифровые строки для URL-адресов вместо использования идентификаторов строк?, где 258510 является идентификатором базы данных, кто-то пытается взломать ваш сайт попытается подключиться к https://stackoverflow.com/questions/2581511.
С помощью stackoverflow это может быть не идентификатор базы данных, и вопросы о stackoverflow не должны быть закрытыми, поэтому это не имеет большого значения, даже если это так.
Но если это был сайт, где важно ограничивать доступ к данным владельцам данных, это потенциально может позволить людям увидеть данные, которых они не должны.
Есть, конечно, вещи, которые вы можете и должны сделать, чтобы они отказались отображать данные, если они не владеют им, но все же лучше сделать URL не идентифицировать идентификатор базы данных. Лучше, как заметил Роб, иметь хэш в какой-то гораздо больший домен или индексом на основе сеанса в набор данных, уже идентифицированных как подходящий, чтобы показать пользователя и доступен только в сеансе входа в систему.
Я бы предположил, что он обфускает информацию и добавляет/увеличивает количество информации, которая может быть передана через этот параметр.
Наличие исходных идентификаторов строк или других немодифицированных параметров базы данных в URL-адресах - это плохая практика безопасности. Гораздо лучше иметь хеши в какой-то большой области.
Некоторые среды также используют это для установки переменных состояния для сеанса. Например, если у вас есть приложение ASP.Net, которое использует cookieless-сеансы, вы найдете аналогичный код в URL-адресе.