Почему веб-сайты генерируют случайные буквенно-цифровые строки для URL-адресов вместо использования идентификаторов строк?

Question

Почему многие сайты (хороший пример YouTube) генерируют строку случайного числа и буквы вместо использования, например, идентификатора строки?

обычно это что-то вроде

bla?v=wli4l73Chc0

вместо

bla?id=83934

Это просто для того, чтобы сократить его, если у вас много строк?Или есть другие хорошие вещи об этом?Потому что я могу себе представить: бла? Id = 23934234234 не выглядит так мило

Спасибо и ура

Answer 1

Они на самом деле не случайные строки. Обычно это числа (обычно идентификаторы строк), которые кодируются в кодировке Base-36 (очевидно, не всегда случай, но многие используют его).

Почему они используют это? Поскольку кодированная числовая строка Base-36 короче оригинала.

Например: 1234567890 в Base-36 равно kf12oi , почти на 50% короче.

См. Эту Википедию статья . Проверьте раздел «Использование на практике», чтобы узнать, кто его использует.

Answer 2

в распределенной среде генерировать случайные числа для идентификаторов проще, чем последовательные числа.

Answer 3

Я проголосовал за ответ Роба, но я также подробно остановлюсь на одном из рисков.

Если вы публикуете ссылку типа Почему веб-сайты генерируют случайные буквенно-цифровые строки для URL-адресов вместо использования строкиids? где 258510 - это идентификатор базы данных, который кто-то пытается взломать на вашем сайте, попытается подключиться к https://stackoverflow.com/questions/2581511.

С помощью stackoverflow это может быть не идентификатор базы данных, и вопросы о stackoverflowдолжен быть частным, так что это не имеет большого значения, даже если это так.

Но если бы это был сайт, где важно ограничить доступ к данным для владельцев данных, это потенциально может позволить людям увидеть данные, которые они не должны 't.

Есть, конечно, вещи, которые вы можете и должны сделать, чтобы они отказывались показывать данные, если им не принадлежат, но все же лучше сделать так, чтобы URL не идентифицировал идентификатор базы данных.Как заметил Роб, лучше иметь хэш в каком-то гораздо большем домене или индекс на основе сеанса в наборе данных, уже определенных как подходящие, чтобы показать пользователя и доступных только во время сеанса вошедшего в систему.

Answer 4

Я, честно говоря, не уверен, почему они не будут использовать уникальный идентификатор (или ObjectID или что-то еще, в зависимости от того, какая база данных), поэтому вы когда-нибудь задумывались, что вместо того, чтобы представлять идентификатор в base-10, они представляли его в более высокой базе (например, 64 или что-то еще в URL), чтобы идентификатор был более компактным в строке запроса? (читай: wli4l73Chc0 - это некое число в неосновной-10)

Answer 5

Я полагаю, что это запутывает информацию и добавляет / увеличивает объем информации, который может быть передан через этот параметр.

Answer 6

Использование необработанных идентификаторов строк или других неизмененных параметров базы данных в URL является плохой практикой безопасности. Гораздо лучше иметь хеши в каком-то большом домене.

Answer 7

Некоторые среды также используют это для установки переменных состояния для сеанса. Например, если у вас есть приложение ASP.Net, которое использует сеансы без файлов cookie, вы найдете похожий код в URL.