#mysql #shiro
#mysql #shiro
Вопрос:
Не вдаваясь в подробности, это вопрос высокого уровня.
Я всегда придерживался идеи, что хранить первичные ключи в местах, где нет ограничений, никогда не является хорошей идеей. Например, хранение первичного ключа в архитектуре в стиле 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? Я просто слишком сосредоточен на искажении ключей? Вы решили эти проблемы? Любая помощь была бы оценена.
Комментарии:
1. Я не поклонник такого подхода (и я не использую Shiro), но случай с призрачными поглощениями — как указывалось — происходит только при повторном использовании идентификатора. Так что не делайте этого. Простой, немного затратный, но довольно эффективный метод заключается в простом использовании GUID . 32 шестнадцатеричных символа, но «хорошо известный» тип и, как правило, «настолько уникальные, насколько это когда-либо понадобится большинству приложений» свойства.
Ответ №1:
Проведя еще несколько исследований с Shrio, я решил последовать предложению pst и просто ссылаться на значения через GUID (возможно, 10-значный буквенно-цифровой вместо этого, чтобы сохранить пространство).
Таким образом, user1 = «пользователь: 441: редактировать» станет «пользователь: 96aae854-fc40-42ff-b948-c8944c2fca92: редактировать» это поможет свести на нет беспокойство по поводу хранения ключей в виде строк.