Стратегия обновления сущностей - PullRequest
0 голосов
/ 28 мая 2009

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

  1. каждая таблица в БД имеет PK, который является руководством, это требуется для нашего решения по многоузловой кластеризации. Идея состоит в том, что мы не хотим показывать это на объекте клиенту через API, потому что это может сделать две вещи,
    1. предоставьте им больше информации, необходимой для их работы, и дайте хакерам больше информации о системе.
    2. Кошмар поддержки заключается в том, что клиент каким-то образом жестко кодирует этот идентификатор, и, если нам нужно изменить, наши клиенты PK подвергаются воздействию.
Решения

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

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

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

Другая проблема заключается в том, как поддерживать частичные обновления, проблема в том, что у вас есть сущность с 10 свойствами, 4 коллекциями и т. Д. ... со списком name + realm и укажите, какое свойство обновлять, вместо того, чтобы вытаскивать поле изменения объекта 1 целиком , отправьте обратно для обновления. Я говорю ленивая загрузка коллекций, но не уверен, имеет ли смысл частичное обновление.

мысли

спасибо!

Ответы [ 3 ]

1 голос
/ 28 мая 2009

Мой подход к структуре безопасности будет выглядеть так:

  • Присвойте что-либо в базе данных внутренний идентификатор (столбец идентификатора, последовательность, независимо от того, поддерживает ли ваша база данных. "Столбец сгенерированного собственного идентификатора" в языке Hibernate). В конце концов, вам это понадобится, и для подгонки - много работы.

  • Если вам нужно передать идентификатор пользователю, сгенерируйте случайное число, убедитесь, что оно еще не использовалось, подключите его к внутреннему идентификатору и передайте его пользователю. Никогда не раздает внутренний идентификатор, а никогда не использует идентификаторы, которые могут быть угаданы взломщиками.

Что касается частичных обновлений, они начинают иметь смысл, только если у вас много объектов с множеством атрибутов. Для 10 атрибутов я бы сказал « преждевременная оптимизация ».

0 голосов
/ 28 мая 2009

Использование GUID для каждой таблицы в качестве первичного ключа звучит как вызов проблемы. Я не видел такого подхода нигде, если я действительно не понимаю вас. Почему бы просто не выдать UID каждому пользователю и работать с UID?

Этот подход наиболее распространен во всех компаниях. UID не PII , так что с законом все в порядке, как и с точки зрения безопасности.

0 голосов
/ 28 мая 2009

Используйте натуральный ключ, если вам нужно предоставить идентификатор клиента. Это не так просто реализовать, но это правильный путь.

Не могли бы вы предоставить немного больше информации об этих частичных обновлениях? Я не получил это. : /

...