Использование поля первичный ключ / идентификатор в качестве идентификатора в URL

каковы плюсы и минусы использования первичного ключа базы данных в качестве идентификатора URL? Например, http://localhost/post/view/13 - 13 является моим основным ключом для моей таблицы сообщений.

некоторые сайты, такие как reddit, используют уникальный идентификатор, который не является первичным ключом, но по-прежнему уникален для идентификации ссылки:

http://www.reddit.com/r/funny/comments/7ynin/the_mystery_of_irelands_worst_driver/

вы можете изменить последнюю часть URL-адреса на все, что хотите, пока /7ynin / является тот же.

Digg, похоже, использует слиток заголовка ссылок для идентификации ссылки:

http://digg.com/space/Liquid_Water_Recently_Seen_on_Mars

в то время как, если я правильно помню, Установка WordPress по умолчанию использует индекс.РНР?p=# как их идентификатор, пока не будут включены fancy url.

Я понимаю, почему для SEO вы хотели бы иметь самый информативный url-адрес, но я просто пытаюсь понять, является ли использование первичного ключа риском для безопасности или просто плохой формой.

9
database-design friendly-url security

6 ответов

вы всегда хотите представить пользователю хороший URL-адрес, а не какой-то неприятный автоматически сгенерированный идентификатор. Но я не думаю, что вы должны сделать "дружественный url" первичным ключом. Вы все равно должны использовать "классический" автоматически увеличенный числовой PK и иметь второй столбец, который является уникальным "дружественным url". Почему?

  1. все таблицы, комментарии, рейтинги таблицы, любые таблицы, которые имеют связь с таблицей содержимого можно использовать числовой первичный ключ. Это означает меньшие индексы и ниже использование памяти.
  2. кто-то захочет изменить дружественных url. Если вы получил первичную цифровую клавишу, вы не придется обновлять зависимые таблицы (или иметь DB сделать это через a каскадное обновление.)
  3. в будущем, вы можете абстрагировать биты URL в другой таблице. Упомянутая таблица может затем сохраните "устаревшие" сопоставления URL-адресов эта проблема перенаправляет на основной "реальная" карта URL. Затем, когда пользователь хочет изменить дружественный URL, тебе не нужно ломать все. этот входящие устаревшие URL-адреса. Не смог. это если ваш первичный ключ был "дружественный URL".
  4. Я все равно был бы склонен использовать числовой первичный ключ во всех моих AJAX goo (например, функция post_new_comment () javascript будет принимать первичный ключ, а не какой-то дружественный URL). Единственный раз, когда я использую удобный URL-адрес, находится в любой структуре URL-адреса пользователя.
  5. а что касается безопасности? Если ваш контент контролируется доступом, вам придется проверять доступ независимо от того, является ли он основным ключ или какой-то дружественный URL.
  6. Если вы разрешаете способы доступа к контенту через первичный ключ, люди могут попробовать подключить случайные идентификаторы. Если ваше требование не только ограниченного доступа к контенту, но и отрицания указанного контента существует, это вопрос формулировки ваших ошибок. Это то же самое, что и с ошибками входа в систему-вы не говорите "имя пользователя не найдено", вы говорите "плохое имя пользователя или пароль". Подключение случайных значений для поиска контента будет проблемой для любого подхода, который вы принимаете, это просто с числовыми ключами есть способ меньше значений, чтобы попробовать.

итог: дружественные URL-адреса? Черт возьми, да. Использовать их в качестве первичного ключа? Черт, нет.

13

Это не по своей сути риск безопасности, хотя он говорит внешним сущностям вещи о вашей системе, что, как правило, рекомендуется избегать.

2

Как вы сказали, точка размещения заголовков непосредственно в URL-адресе-SEO. Наличие ключевых слов в URL-адресе оказывает значительное влияние на результаты поиска.

однако, несколько других мыслей, связанных с вашими примерами:

  • Я не уверен, почему вы предполагаете, что Reddit буквенно-цифровой ключ не является основным, нет ничего, что заставляет первичные ключи быть числовыми. Если это уникальный идентификатор поста, нет никаких причин не использовать его в качестве первичного ключа (или, по крайней мере часть его.)

  • Digg фактически обеспечивает уникальность названий (возможно, только внутри определенной категории, я не был в Digg годами, поэтому я не могу вспомнить). Раньше я видел это довольно часто с повторяющейся историей, имеющей URL-адрес:

    http://digg.com/space/Liquid_Water_Recently_Seen_on_Mars_2

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

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

2

Если вы не включите первичный ключ(ы) в URL/link, затем вы должны сделать какой-то временный синтетический ключ, а затем вы должны сохранить сопоставление этого ключа в сеансе для пользователя. Это добавляет больше состояния / использования памяти / что-то, чтобы сломать ваше приложение.

Если значение действительно чувствительно, это might стоит того, чтобы скрыть его. Однако скрытие ключа на самом деле не делает его безопасным, не так ли? Вам нужно проверить роли пользователей в любом "контроллере" (сервлете, коде, любом) перед предоставлением доступа к элементу.

2

a con: любой посетитель может легко попробовать и угадать другие идентификаторы, которые могут быть не то, что вы хотите.

1

Reddit также использует числовой идентификатор, но преобразуется с помощью база 36, поэтому он отображается как строка. Это как шестнадцатеричное число, которое на самом деле также является строкой. Единственное отличие-это основа.

база 36-это "самый компактный регистр буквенно-цифровой системе счисления, используя символы ASCII" и он легко encodable и декодируемыми. Почему 36? A-Z = 26 + 0-9 = 10.

1