Одно маленькое уточнение, что я нашел в целом за все отрицать было
@DenyAll аннотаций можно использовать для ограничения доступа бизнес-интерфейса от любого, авторизованы или нет. Этот метод все еще может быть вызван из самого класса компонента.
Таким образом, он может использоваться для метода, который по какой-либо причине является публичным или был подвергнут воздействию (возможно, он реализует интерфейс), но никогда не должен вызываться непосредственно извне. Однако они могут быть вызваны изнутри (внутри класса).
вот link
Один реальный пример, который я могу дать вам (что вполне связаны с моей работой). У нас есть 2 бизнес-единицы с одинаковой базой кода. Теперь в одном блоке есть функция, когда какой-либо мобильный посредник может напрямую вызвать услугу, которая отменяет ваучер непосредственно на стороне оператора, а в другом блоке нам нужно блокировать это из-за какого-то бизнес-правила. Поскольку мы используем один и тот же интерфейс в обеих системах, поэтому в одной системе мы заблокировали его использование, используя denyall
Надеюсь, это даст вам четкую идею.
Результат применения этих аннотаций полезен для экземпляра прокси-уровня компонента (когда другие bean-компоненты называют компонент с помощью аннотированного метода), но вы все равно можете использовать этот метод внутри одного и того же компонента не по экземпляру прокси, возможно, вы можете использовать эту комбинацию, если хотите использовать метод только внутренне. –
есть ли какая-либо документация, где я могу получить более подробную информацию? Не могли бы вы привести пример, когда кто-то хотел бы иметь такую конфигурацию безопасности – Zack