Как мне защитить свое веб-приложение, написанное с использованием Wicket, Spring и JPA? - PullRequest
18 голосов
/ 23 февраля 2010

Итак, у меня есть веб-приложение, которое использует платформу Wicket 1.4 и использует бины Spring, Java Persistence API (JPA) и шаблон OpenSessionInView. Я надеюсь найти модель безопасности, которая была бы декларативной, но не требовала бы настройки XML - я бы предпочел аннотации.

Вот варианты на данный момент:

  1. Spring Security ( guide ) - выглядит завершенным, но каждое найденное мной руководство, которое объединяет его с Wicket, все еще называет его Acegi Security, что заставляет меня думать, что оно должно быть старым.

  2. Wicket-Auth-Roles ( guide 1 и guide 2 ) - Большинство руководств рекомендуют смешивать это с Spring Security, и мне нравится декларативный стиль @Authorize ( "Role1", "роль2", и т.д.). Меня беспокоит необходимость расширения AuthenticatedWebApplication, поскольку я уже расширяю org.apache.wicket.protocol.http.WebApplication, а Spring уже проксирует это за org.apache.wicket.spring.SpringWebApplicationFactory.

  3. SWARM / WASP ( guide ) - Это выглядит самым новым (хотя основной вкладчик скончался много лет назад), но я ненавижу все текстовые файлы в стиле JAAS, которые объявляют разрешения для принципалов , Мне также не нравится идея создания класса Action для каждой вещи, которую может захотеть сделать пользователь. Безопасные модели также не сразу очевидны для меня. Кроме того, нет примера Authn.

Кроме того, похоже, что многие рекомендуют смешивать первый и второй варианты. Хотя я не могу сказать, что такое лучшая практика.

Ответы [ 2 ]

8 голосов
/ 23 февраля 2010

Я не знаю, видели ли вы это сообщение в блоге , поэтому я добавляю его сюда в качестве ссылки и просто процитирую конец:

Обновление 2009/03/12: тех, кто заинтересован в защите калитки приложения также должны знать, что есть альтернатива Калитка-охранник, называется калитка-авт-роли. Эта тема даст вам хороший обзор статус двух рамок. Интеграция wicket-auth-ролей с Безопасность Spring покрыта здесь .
Одна неотразимая особенность wicket-auth-role - это способность настроить авторизацию с Java аннотаций. Я нахожу это как-то больше элегантный, чем централизованный конфигурационный файл. Есть пример здесь .

Исходя из приведенной выше информации и предоставленной вами информации, а также потому, что я предпочитаю аннотации, я бы пошел на Wicket-Auth-Roles с Spring Security (т.е. guide 2 ). Расширение AuthenticatedWebApplication не должно быть проблемой, так как этот класс расширяет WebApplication. И вытащить объект приложения из контекста пружины с помощью SpringWebApplicationFactory также должно работать.

И если ваши опасения действительно велики, это было бы довольно легко и быстро подтвердить с помощью тестового ИМО:)

2 голосов
/ 28 апреля 2010

Мы используем Wicket-security уже много лет, и мы использовали ее вместе с файлами jaas и с аннотациями. Определить jaas-файлы довольно сложно, а поддерживать их практически невозможно ...

С аннотациями нужно определить действия и принципы для каждой страницы. Это отнимает много времени, однако позволяет пользователю динамически определять роли и полномочия. Также можно протестировать все принципалы с помощью WicketTester.

Каждый из 3 пакетов имеет свои (не) преимущества, это вопрос вкуса, а также зависит от размера приложения.

...