Spring MVC - Spring Security - Контроллеры Общая архитектура - Лучшие практики

Question

Недавно я пытаюсь узнать Весну. Я создал простой веб-приложение, которое в основном должны иметь 2 типа пользователей:

• клиентов
• Админ

Вы можете представить себе приложение как классический торговый веб-приложение, где администраторы имеют привилегии, чтобы добавить новые предметы, а клиенты могут видеть перечисленные элементы и добавлять их в свои тележки. Теперь мой вопрос о общей архитектуре системы, который должен быть одним из примеров лучшей практики Spring Framework.

Я могу перечислить здесь пункты об этом архитектурных решениях, и вы можете сказать, будете ли вы сделать это по-другому:

1- У меня есть 2 разных диспетчерские сервлет. Таким образом, ссылки под публикой будут для клиентов, а администратор будет для админов.

<servlet-mapping> 
    <servlet-name>public-dispatcher</servlet-name> 
    <url-pattern>/public/*</url-pattern> 
</servlet-mapping> 

<servlet-mapping> 
    <servlet-name>admin-dispatcher</servlet-name> 
    <url-pattern>/admin/*</url-pattern> 
</servlet-mapping> 

2- Весной-security.xml у меня есть для аутентификации администратора, как это:

<intercept-url pattern="/admin/**" access="ROLE_ADMIN" /> 

(Все действия в рамках URL/администратор/будет защищен паролем)

3- У каждого сервлета есть viewResolver, указывающий на другую папку, содержащую jsps:

/WEB-INF/admin-jsp/ (admin jsps) 
/WEB-INF/public-jsp/ (customer jsps) 

4- Допустим, у меня есть эти Объекты Домена: Товар, ShoppingCart, Клиент и т. Д. Для каждого объекта домена у меня есть ОДИН класс контроллера i.e ItemController, который обрабатывает целые запросы (клиенты и администраторы) об элементе.

@Controller 
@RequestMapping("/item") 
@SessionAttributes({"cart"}) 
public class ItemController { ... 

Каждое из этих решений имеет смысл, когда я думаю о них один за другим. Но на самом деле ясно, что, поскольку я не видел никакого большого приложения Spring (интернет содержит множество небольших частей кода, которые не дают представления о целом), здесь что-то не так.

Для экземпляра: Я могу назвать этот url как client/public/item/addNewItem (который на самом деле существует для админов), и метод будет выполнен, поскольку ItemController (/ item) доступен для всех. Но так как у меня есть jsps в двух разных местах, весна будет вызывать ошибку, которой вид не существует. Аналогично администратору, когда я могу позвонить URL/admin/item/addToCart ....

Что такое лучшая арка. реализации целого? Должен ли я определить еще несколько URL-адресов в конфигурации безопасности? Например:

<intercept-url pattern="/admin/**" access="ROLE_ADMIN" /> 
<intercept-url pattern="/admin/addNewItem" access="ROLE_ADMIN" /> 

ИЛИ

Если я определил различные контроллеры для различных ролей?

@RequestMapping("/public/item") 
    @SessionAttributes({"cart"}) 
    public class PublicItemController { ... 

@RequestMapping("/admin/item") 
    public class AdminItemController { ... 

ИЛИ

Любой другой путь? Как это сделать в большой системе, где есть множество ролей, контроллеров и т. Д.

Answer 1

Я знаю, что я опоздал на эту дискуссию (вы могли бы решить вашу проблему сейчас), но здесь это для всех поздних желающих, как me :)

С гарантией Spring (или любой защитой) мы обычно контролируем доступ к нашему приложению «RESOURCES» (который доступен через URL-адреса приложения), и для этого нам нужно сопоставление ROLE-TO-RESOURCE.

1. Это нехороший подход к использованию двух разных сервлетов диспетчера, если у вас для этого нет серьезной причины. И использовать «Spring Security», одного достаточно.

2. Это подход, с которым вам следует начать, позволяя получить доступ к шаблонам URL на основе пользовательских ROLE. Классы среды безопасности Spring должны проверять пользовательские ROLE перед тем, как разрешить доступ к запрашиваемому URL.

3. Мы обеспечиваем логические ресурсы, мы в любом случае не позволяем пользователям напрямую обращаться к нашим физическим ресурсам. Держите свои JSP внутри WEB-INF, и вам хорошо идти.

4. Вам не нужно иметь разные контроллеры для разных ROLE. Методы контроллера служат для обслуживания веб-запросов, и если пользователю не разрешен доступ к определенному URL-адресу, ваш метод контроллера, обслуживающий этот URL-адрес, никогда не будет выполнен.

Answer 2

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

1. Вместо использования проверки компонентов объявлять каждый контоллер вручную в формате XML.
2. Если у вас есть мало исключений, вы можете использовать filters. Создайте две новые аннотации, OnlyForAdminController и OnlyForPublicController. Аннотировать соответствующие классы. Затем настроить параметры компонент сканирования для каждого диспетчера сервлета:

<!-- For public --> 
<context:component-scan base-package="com.yourproject.conrollers"> 
    <context:exclude-filter type="annotation" expression="com.yourproject.annotation.OnlyForAdminController"/> 
</context:component-scan> 


<!-- For admin --> 
<context:component-scan base-package="com.yourproject.conrollers"> 
    <context:exclude-filter type="annotation" expression="com.yourproject.annotation.OnlyForPublicController"/> 
</context:component-scan> 

В реальных системах этого типа (интернет-магазина) большую часть времени вы будете иметь некоторые специальные требования для государственных и администратора пользователей. Например, в случае с пользователем ItemController пользователь может видеть статистику продаж как дополнительную информацию, где публичный пользователь может увидеть список из 5 ранее просмотренных элементов. Поэтому с точки зрения производительности у вас будет два отдельных контроллера. В любом случае вы можете начать повторное использование некоторых контроллеров, где это возможно, и разделить эти контроллеры на пользователя позже, когда будет запрошено какое-то особое поведение. Ваша техника будет намного интереснее, если у вас есть только незначительные различия между двумя типами пользователей.

Answer 3

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

2. Да, звучит хорошо

3. Опять же, я не вижу, как расщепление администратора и общественные JSPs в отдельные каталоги собирается, чтобы помочь вам. Это может вас смутить, если у вас есть JSP, которые являются общими для обеих областей.

4. Это зависит от ваших личных предпочтений. Я определяю свои вещи безопасности в XML, но много людей предпочитают аннотации