Управление пользователями для электронной коммерции

Question

В настоящее время я работаю над приложением электронной коммерции. Приложение имеет разные пользователи:

1. Клиенты
2. Merchants
3. Логистика
4. администратора

Текущая структура БД имеет другую таблицу для каждого из этих типов пользователей. И я работаю над настройкой безопасности для back-end java-based-rest-application.

Я застрял на том, как это реализовать. Я создал следующий файл безопасности весны.

1. Создан и зарегистрирован фильтр. (AuthenticationTokenProcessingFilter)
2. В классе фильтра, проверяю для запроса URL-адресов, чтобы определить, какие DAO я должен использовать для проверки пользователя.

** весна-security.xml **

<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" 
xmlns:security="http://www.springframework.org/schema/security" 
xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans-4.0.xsd 
http://www.springframework.org/schema/context 
http://www.springframework.org/schema/context/spring-context-4.0.xsd 
http://www.springframework.org/schema/security 
http://www.springframework.org/schema/security/spring-security-3.2.xsd"> 
<security:http pattern="/rest/users/**" entry-point-ref="restAuthenticationEntryPoint" 
    use-expressions="true" auto-config="false" create-session="stateless"> 
    <security:custom-filter ref="authenticationTokenProcessingFilter" 
     position="PRE_AUTH_FILTER" /> 
    <security:intercept-url pattern="/rest/users/{userId}/orders/**" 
     access="hasRole('ROLE_CUSTOMER','ROLE_ADMIN')" /> 
    <security:logout /> 
</security:http> 

<security:http pattern="/rest/admin/**" entry-point-ref="restAuthenticationEntryPoint" 
    use-expressions="true" auto-config="false" create-session="stateless"> 
    <security:custom-filter ref="authenticationAdminFilter" 
     position="PRE_AUTH_FILTER" /> 
    <security:intercept-url pattern="/rest/admin/**" 
     access="hasRole('ROLE_ADMIN')" /> 
    <security:logout /> 
</security:http> 

<security:http pattern="/rest/business/**" 
    entry-point-ref="restAuthenticationEntryPoint" use-expressions="true" 
    auto-config="false" create-session="stateless"> 
    <security:custom-filter ref="authenticationTokenProcessingFilter" 
     position="PRE_AUTH_FILTER" /> 
    <security:intercept-url pattern="/rest/business/{businessId}/orderItems**" 
     access="hasRole('ROLE_MERCHANT')" /> 
    <security:logout /> 
</security:http> 

<security:http pattern="/rest/merchant/**" 
    entry-point-ref="restAuthenticationEntryPoint" use-expressions="true" 
    auto-config="false" create-session="stateless"> 
    <security:custom-filter ref="authenticationTokenProcessingFilter" 
     position="PRE_AUTH_FILTER" /> 
    <security:intercept-url pattern="/rest/merchant/**" 
     access="hasRole('ROLE_MERCHANT_ADMIN')" /> 
    <security:logout /> 
</security:http> 



<bean id="authenticationTokenProcessingFilter" class="com.resource.security.TokenAuthenticationFilter"> 
    <constructor-arg type="java.lang.String"> 
     <value>/rest/**</value> 
    </constructor-arg> 
</bean> 


<bean id="restAuthenticationEntryPoint" 
    class="com.resource.security.RestAuthenticationEntryPoint"> 
</bean> 


<security:authentication-manager alias="authenticationManager" /> 

ПРОБЛЕМЫ

1. Если конкретный URL должен быть вызван двумя ролями я не уверен, как это сделать, поскольку я проверяю и назначаю одну роль только в фильтре. Например: администратор может получить доступ к любым URL-адресам, к которым обращается клиент.

Answer 1

Вместо использования нескольких таблиц для управления несколькими пользователями создайте единую таблицу для всех, а затем разделите их с помощью ролей. Используйте ROLE_CUSTOMER, ROLE_MERCHANT, ROLE_ADMIN и ROLE_LOGISTICS. Затем вы можете использовать hasRole, чтобы определить, кто может получить доступ к URL-адресу.

Почему вы используете разные таблицы, если я могу спросить? Я не совсем понимаю преимущества, кроме повторного использования имен пользователей.