0 Вопрос: Защита приложения с помощью AspectJ против SpringInterceptor

вопрос создан в Wed, May 8, 2019 12:00 AM

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

Я пишу API в Spring, защищенный под JWT и OAuth2, и не хочу использовать уровень Spring Security. Другими словами, я хочу создать свой собственный уровень безопасности со своими правилами и т. Д ...

Тем не менее, я нашел два варианта создания этого слоя за границей.

  • AspectJ
  • Spring Interceptors

AspectJ

С AspectJ я могу создать аспект, чтобы обернуть каждый метод, аннотированный @MySecurityAnnotation(role="bar", permission="foo", group="blah"), и предоставить, чтобы ни один пользователь не вызывал joinPoint без правильного разрешения.

При таком подходе код запутывается, потому что AspectJ внедряет код в конечные файлы .class . (пожалуйста, поправьте меня, если я говорю ерунду). С другой стороны, мне не нужно проверять с помощью отражения аннотированных типов, потому что код уже упакован.

Spring Interceptor

С помощью перехватчика, как следует из названия, создается одна точка перехвата для каждого HandlerMethod, и теперь мне нужно проверять каждый запрос, если запрос указывает на HandlerMethod, как это должно быть для проверки учетных данных пользователей. р>

Так что я думаю , что это медленно, чем реализация AspectJ, потому что нам нужно проверить с помощью отражения аннотированные методы, чтобы получить роли /разрешения, необходимые для доступа к конечной точке.

Хорошо, я объяснил оба сценария, теперь я просто хочу знать, какой из них будет лучшим и в какой ситуации. Есть кто-то, кто часами думает об этом, как я? Есть ли другая реализация, не указанная в списке? Есть ли лучший способ реализовать безопасность в Spring API без уровня Spring Security? Пожалуйста, дайте мне знать.

Спасибо за всю эту помощь.

    
0
  1. Лучше всего не изобретать свою систему безопасности. Какой из них использовать, зависит от того, что вы хотите обезопасить. Если вы хотите обезопасить услуги, то не существует HandlerInterceptor, который вам поможет. AspectJ также применяется с использованием прокси при использовании Spring, если только вы не настроили время компиляции. Однако, как уже упоминалось, не пытайтесь заново изобрести каркас безопасности, есть множество других, которые используют его вместо этого. Обычно они делают больше, чем просто доступ на основе ролей /групп.
    2019-05-08 18: 26: 26Z
  2. Здравствуйте @ M.Deinum Я читаю несколько статей об Apache Shiro. Что вы мне порекомендуете?
    2019-05-08 18: 35: 00Z
  3. Я склонен к Spring Security, так как он действительно хорош, но Apache Shiro также имеет интеграцию Spring.
    2019-05-09 05: 23: 17Z
  4. @ M.Deinum в принципе прав, но выразил технические детали таким образом, чтобы его легко понять в AspectJ: Spring AOP основан на динамических прокси , AspectJ однако, о котором говорил OP (подсказка: измененные файлы классов), не имеет значения, независимо от того, используется ли он через ткачество во время компиляции, как сказал М. Дейнм, или через ткачество во время загрузки, которое Это обычный способ, которым пользователи Spring применяют AspectJ, и он хорошо описан в руководстве по Spring. Таким образом, с помощью LTW вы можете сохранить исходные файлы классов (хотя я бы сказал, что компилятор AspectJ их не «запутывает») и обладают всеми возможностями AspectJ.
    2019-05-09 06: 23: 15Z
  5. AspectJ при использовании со Spring по-прежнему использует ту же инфраструктуру Spring AOP. AspectJ применяется так же, как и обычные перехватчики aopalliance. Это изменится, только если вы сами настроите ткачество во время компиляции ИЛИ ткачество во время загрузки. Последний не включен по умолчанию, и поэтому все AOP по умолчанию (независимо от способа выражения AOP) используются прокси.
    2019-05-09 06: 24: 42Z
0 ответов                              0                         
источник размещен Вот