Это плохая практика выставлять внутренние идентификаторы БД в URL? - PullRequest
5 голосов
/ 28 марта 2012

Это плохая практика, чтобы выставлять внутренние идентификаторы БД в URL?

Например, предположим, у меня есть таблица users с некоторыми идентификаторами (первичный ключ) для каждой строки. Будет ли раскрытие URL myapp.com/accountInfo.html?userId=5, где 5 фактическим первичным ключом, рассматриваться как «плохая вещь» и почему?

Также предположим, что мы правильно защищаемся от SQL-инъекций.

Меня больше всего интересуют ответы, связанные со стеком веб-технологий Java (отсюда и тег java), но общие ответы также будут очень полезны.

Спасибо.

Ответы [ 5 ]

7 голосов
/ 28 марта 2012

Это не плохая вещь в URL-адресе, так как он не имеет большого значения для конечного пользователя - он плох, только если вы полагаетесь на это значение при запуске вашего приложения.Например, вы не хотите, чтобы пользователь заметил, что userId = 5, и измените его на userID = 10, чтобы отобразить учетную запись другого человека.

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

7 голосов
/ 28 марта 2012

Это основано на том, как вы анализируете URL.Если вы допускаете слепые инъекции SQL, это плохо.Вам нужно только подтвердить идентификатор из пользовательского ввода.

Stackexchange также помещает идентификатор строки в URL, как вы можете видеть в адресной строке.Хитрость заключается в том, чтобы разобрать часть и получить все возможные SQL.Самый простой способ - проверить, что id является числом.

3 голосов
/ 28 марта 2012

Да, это плохо. Вы раскрываете детали реализации. Как плохо? Это зависит от. Это заставляет вас делать ненужные проверки пользовательского ввода. Если другие приложения запускаются в зависимости от этого, вы больше не можете изменять схему базы данных.

1 голос
/ 28 марта 2012

Хорошо использовать идентификатор базы данных в URL-адресах, потому что этот идентификатор никогда не должен меняться в жизни объектов (строк в дБ).Таким образом, URL долговечен - самый важный аспект URL.См. Также Классные URI не меняются .

0 голосов
/ 02 января 2014

PK предназначены для системы.
Для пользователя это может означать другое значение:
Например, давайте рассмотрим следующие ссылки.Используя первичный ключ, он отображает элемент в разделе products
productA, productB, productC;

(A) http://blahblahsite.com/browse/productA/111 (pkey)
(B) http://blahblahsite.com/browse/productB/112 (pkey)
(C) http://blahblahsite.com/browse/productC/113 (pkey)
Пользователь по ссылке B может чувствовать, что в ProductB 112 пунктов, что вводит в заблуждение.

Также это вызовет проблемы при объединении таблиц, так как PK будет автоматически увеличен.

...