Не вдаваясь в подробности, это вопрос высокого уровня.
Я всегда придерживался идеи, что никогда не стоит хранить первичные ключи в местах, где нет ограничений. Например, сохранение первичного ключа в архитектуре стиля EAV ("USER_ID",144). Если этот пользователь когда-либо будет удален, он не будет отражен в сопоставлении EAV и вызовет проблемы в дальнейшем.
Итак, я создаю новое приложение, используя shiro в качестве security/permission фреймворка, и мне нужны пользователи, чтобы иметь возможность редактировать себя, но не другие пользователи, мне также нужны другие пользователи, чтобы иметь возможность редактировать кого-либо. Достаточно просто:
user1 = "user:441:edit"
user2 = "user:edit"
Кроме того, у меня мог быть кто-то, кто может редактировать только подмножество пользователей, что-то вроде этого
user3 = "user:459:edit","user:460:edit","user:461:edit"
Или кто-то, кто может редактировать пользователей, которые находятся в отделе, но только в этом отделе
user4 = "department:5898:user:edit"
Если кто-то из списка user3 будет удален, то нет способа обновить разрешения этого пользователя без всякой магии (пройдя все разрешения и найдя те, которые нужно удалить).
Теперь я не планирую сбрасывать ключи, но если это когда-нибудь произойдет, и я НЕ очищаю старые ключи, у меня может быть возможность пользователям внезапно редактировать пользователей, которые были недавно созданы после повторного использования старых ключей.
Я мог бы смягчить некоторые из них, используя сгенерированный код ("user:ciS84nFSHK:edit"), который уникален для ВСЕХ ТАБЛИЦ, чтобы управлять удалением разрешений. Однако добавление нескольких сотен миллионов записей заставляет меня думать, что это может быстро стать громоздким.
Я неправильно использую Shiro? Я просто слишком сосредоточен на том, чтобы ключи искалечены? Вы решили эти проблемы? Любая помощь будет оценена.