Это плохая идея использовать идентификатор таблицы базы данных в качестве внешнего идентификатора API?

Question

Мы разрабатываем службу HTTP с внешним API, который должен будет хранить некоторые элементы, которые потребителям внешних API, возможно, потребуется впоследствии получить.Все хранится в таблице foos, и текущий план состоит в том, чтобы просто использовать первичный ключ идентификатора таблицы в качестве внешнего уникального идентификатора.Моя интуиция говорит мне, что это плохой дизайн, но я не смог эффективно аргументировать свою ситуацию, отчасти потому, что не могу четко сформулировать причины.

Вот единственные недостатки, которые я могу себе представить:

• Что, если мы хотим изменить схему?Нам придется заново заполнить все, чтобы убедиться, что их идентификаторы остались нетронутыми, или внедрить еще один столбец уникальных идентификаторов во время перемещения
• Незначительный (?) Риск безопасности (я знаю, что безопасность через неизвестность не безопасна и т. Д.)

Есть ли другие серьезные недостатки, или я просто параноик?Буду также признателен за ссылки на опубликованные статьи, в которых говорится об этом!

Answer 1

Я собираюсь пойти дальше и сказать, что если ваша база данных заблокирована, то это не имеет значения, если:

• Совместное использование ключей API означает потерю в C.I.A. пользовательской информации.
• Вы облегчаете пользователям вызовы вашего API без аутентификации второго уровня.

Я уверен, что вы уже понимаете, что принятие мер против внедрения SQL-кода не позволит никому воспользоваться этой информацией, однако знание диапазона индекса может означать, что кто-то узнает, что на 1 меньше или на 1 больше в диапазоне индекса материальный ключ, который будет использоваться для доступа к вашему API.

---

Например:

Если вы можете получить доступ к своему API через URL-адрес без входа в систему, тогда использование диапазона индексов - это плохо.
http://mysite.com? APIkey = 145
Если я знаю, что мой ключ 145 , то 144 и 146 , вероятно, также будут работать для совершения вызова.

Использование схемы GUID - способ справиться с этим, но с этим вы делаете другие жертвы :
ID (индекс): 145
ID (GUID): C87FC84A-EE47-47EE-842C-29E969AC5131

---

Или, наконец, вы можете добавить еще один столбец, чтобы сохранить случайный хеш в качестве уникального ключа API, как вы сказали:
ID (хэш): da39a3ee5e6b4b0d3255bfef95601890afd80709

Answer 2

Это совершенно безопасно.Идентификаторы будут сохранены и восстановлены вместе с остальными данными, поэтому проблем здесь нет.Также нет проблем с безопасностью, о которых я могу думать.Является ли это плохим дизайном - дело вкуса.

IIRC API eBay и PayPal работают таким образом, но я не могу привести ссылку на это.

Answer 3

Я согласен с вами из-за вашего первого пункта:

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