Как я могу защитить свой webapp, написанный с использованием Wicket, Spring и JPA?
Итак, у меня есть веб-приложение, использующее среду Wicket 1.4, и оно использует Spring beans, Java Persistence API (JPA) и шаблон OpenSessionInView. Я надеюсь найти модель безопасности, которая декларативна, но не нуждается в настройках конфигурации XML - я бы предпочел аннотации.
Вот варианты:
-
Spring Безопасность (guide) - выглядит полным, но каждый справочник, который я нахожу, объединяет его с Wicket, все еще вызывает это Acegi Security, которая заставляет меня думать, что она должна быть старой.
-
Критические кривые (руководство 1 и руководство 2). Большинство руководств рекомендуют смешивать это с помощью Spring Security, и мне нравится декларативный стиль @Authorize ( "ROLE1" , "ROLE2" и т.д.). Я обеспокоен необходимостью расширения AuthenticatedWebApplication, так как я уже расширяю org.apache.wicket.protocol.http.WebApplication и Spring уже проксирует, что за org.apache.wicket.spring.SpringWebApplicationFactory.
-
SWARM/WASP (guide) - Это выглядит новейшим (хотя основной вкладчик скончался много лет назад), но я ненавижу все текстовые файлы в стиле JAAS, объявляющие разрешения для руководителей. Мне также не нравится идея создания класса Action для каждой отдельной вещи, которую пользователь может захотеть сделать. Безопасные модели также не сразу очевидны для меня. Кроме того, нет примера Authn.
Кроме того, похоже, что многие люди рекомендуют смешивать первый и второй варианты. Однако я не могу сказать, что такое лучшая практика.
Ответы
Ответ 1
Я не знаю, видел ли вы этот пост в блоге, поэтому я добавляю его здесь как ссылку, и я просто процитирую конец
Обновление 2009/03/12: те, кто заинтересован в защите калитки приложения также должны знать, что существует альтернатива Wicket-Security, называемая калитка-авт-роли. Этот потокдаст вам хороший обзор статус двух структур. Интеграция калитки-auth-ролей с Spring Безопасность распространяется здесь.
Одной из неотъемлемых особенностей Калитка-аут-роли - это способность настроить авторизацию с помощью Java аннотаций. Я нахожу это как-то больше элегантный, чем централизованный Файл конфигурации. Есть Пример здесь.
Основываясь на информации выше и той, которую вы предоставили, и потому, что я тоже предпочитаю аннотации, я бы пошел на Wicket-Auth-Roles с помощью Spring Security (т.е. руководство 2). Расширение AuthenticatedWebApplication не должно быть проблемой, так как этот класс расширяет WebApplication. И вытягивание вашего объекта приложения из контекста Spring с помощью SpringWebApplicationFactory также должно работать.
И если ваши проблемы действительно большие, это было бы довольно легко и быстро подтвердить с помощью теста IMO:)
Ответ 2
Мы используем Wicket-security уже много лет, и мы использовали его вместе с файлами jaas и аннотациями. Определение файлов jaas - довольно сложная проблема, и поддерживать их практически невозможно...
С аннотациями необходимо определить действия и принципы для каждой страницы. Это timeconsuming, но это позволяет вам позволить пользователю определять роли и авторизации динамически. Также можно протестировать все принципы, используя WicketTester.
Каждый из 3-х пакетов имеет преимущества (это), это вопрос вкуса, а также зависит от размера приложения.
