dakeiras,

Кстати, посмотрел мельком код вашего очередного решения
Правильно ли я понимаю:
1) При изменении пути к контроллеру в случае вашего решения необходимо так же писать скрипт для обновления базы данных (изменение urlTemplate или как он там)
2) Если у меня в body передается что-то в формате, не представимом в виде строки (например - protobuf) - ваше решение не позволяет проверить содержимое body
3) Что с проверкой безопасности в случае multipart request?
4) Что с проверкой безопасности, если в body text/plain, но размеров в пару гигабайт?:)
5) Кеширования регулярных выражений нет, то есть паттерны разбираются на каждый запрос?

Это будет делаться через гуй, которого пока нет. Поэтому пока через базу там.
Гуй уже в процессе создания, на Vue.js.

Нежизнеспособно. Разработчик должен при выполнении рефакторинга каким-то образом узнать, что нужно пойти в какой-то там UI/базу и поменять там URL. При этом еще и требуется написать инструкцию для обновления (например, для релизного стенда - "при выкатывании версии 2 сходите в UI и поменяйте URL").

dakeirasПроверка Body концептуально хитрая задача.
Только вот в случае спринга я могу это сделать в контроллере, аспектом, HandlerInterceptor. Скорее всего есть еще способы, лень искать. У вас - только во внешней системе. И кастомный фильтр не спасает - в таком случае мне необходимо обновлять этот фильтр всякий раз при изменении контракта.

P.S. Мне кажется или это - волшебно?

Причем тут гуй?
1) Ключ вообще лучше хранить в настройках
2) Для накатывания состояния базы есть liquibase например
3) Вы чистите состояние при каждом рестарте приложения, то есть любые изменения стираются

dakeirasА правильно было бы проверять доступ в гейтвее, на уровне инфраструктуры.
И что делать с вашим "решением", если логика работы зависит от прав пользователя?:)

dakeirasРазработчик НЕ должен управлять доступом. Им должен управлять офицер безопасности.
1) Разработчик должен корректно реализовать ПРОВЕРКИ доступа пользователя. Управлять доступом конкретных пользователей он естественно не должен
2) Что делать в случае не http протокола?:) Например в одном из моих проектов можно взаимодействовать с системой через JDBC/ODBC драйвер. Каким образом это вообще реализуемо в вашей системе - никаким?:)

dakeiras Спринг не предоставляет никаких встроенных механизмов автоматизации проверки доступа в ACL, это отдаётся на усмотрение разработчика и сводится к написанию кода безопасности.
1) Ну то есть вы в этом топике сравниваете апельсин и лопату?
2) @PreAuthorize("isFullyAuthenticated() and @mySecurityBean.hasAccessTo(#objectId)") - не является "автоматизацией проверки доступа в acl"? или имеется в виду, что таки нужно реализовать этот самый mySecurityBean?

dakeiras,

dakeirasЛогика не должна зависеть от прав доступа.

Логика легко может зависеть от роли пользователя. Вы видимо считаете, что роли безопасности не могут быть частью "бизнес процессов". Это не так.


dakeirasПравильно делать отдельные приложения для юзеров и отдельные для админов. Это улучшает качество кода, упрощает тестирование и внесение изменений.

"Менеджер" в автосалоне может сделать 2 скидки в день, а "старший менеджер" - 10.
Одновременно с этим "менеджер" не может продать машину без одобрения "старшего менеджера".
1) Видимо кто-то из них "админ", а кто-то "юзер"?:)
2) Вы видимо предлагаете реализовать 1 ограничение минуя правовую модель, а второе - в ней? А как у вас можно проверить состояние одобрения?
3) нужно для каждого по отдельному приложению сделать?:)
P.S. Пример выше - выдуманный

У меня ощущение что вы взяли из нормальных SECAAS только 1 функцию - ограничение доступа к ресурсам - и пытаетесь ее продать
githubMonthly:

0-5000 successfully granted authorizations - free
Each extra: $0.01 per each successful authorization grant
Кстати, а что будет, если я защищу что-либо вашей системой, а ее взломают? Сколько вы мне денег в таком случае заплатите?

P.S. А что если у меня приложение с сессиями и url + body ни разу не достаточны для понимания, что делает пользователь?

Классный пример из сторонней области. Вот вам более релевантный:
1) Злоумышленник узнал мой логин и пароль. Я срочно звоню админу с просьбой срезать мне все права. Злоумышленник продолжает спокойно работать со старым токеном. Прекрасное решение, я считаю.
2) Стажеру Васе случайно дали право на функцию "Achtung!!! Налоговая! Отправить сервер с черной бухгалтерией в космос!!!", но спохватились и через 10 секунд забрали. Но у Васи видимо доступ должен остаться :)