Каков наилучший подход к созданию веб-приложения на основе ролей?

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

  • Student
  • Профессор
  • Администратор

Мне нужно иметь логин в начале, а затем после ввода учетных данных приложение необходимо перенаправить на домашнюю страницу.

Вопрос здесь: как мне обрабатывать роли? Должен ли я иметь пространство имен для каждой роли? i.e: students/index.jsp, professors/index.jsp, admin/index.jsp или имеют общее пространство имен для всех ролей? что-то вроде home/index.jsp? а затем использовать декоратор/составной шаблон, чтобы меню имело разные параметры в зависимости от роли?

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

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

Спасибо за ваше время и помощь.

Ответ 1

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

У вас должна быть страница для каждой функции и ограничение доступа на основе ролей пользователей. (например, некоторые пункты меню не видны для Студента, но показаны для профессоров и админов.)

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

Я думаю, что JSP по мере того, как технология стареет, поэтому вам, вероятно, следует начать изучение Angular.

Так как получение рабочей установки Spring/Angular не является тривиальным, я бы рекомендовал вам использовать JHipster application generator, который ведет вы в течение всего процесса с помощью мастера (вам нужно просто ответить на некоторые вопросы - когда вас спросят о типе select monolithic web application): затем он создает рабочую конфигурацию проекта с поддержкой на основе ролей в соответствии с современными рекомендациями.

Если вы хотите узнать о правильном управлении доступом на основе ролей в современном веб-приложении, глядя на решения, используемые в приложении JHipster, я считаю лучшим и самым быстрым решением:

  • он использует Spring Функции безопасности для ограничения вызовов в Java Бэкэнд: посмотрите на использование аннотации org.springframework.security.access.annotation.Secured в сгенерированном проекте
  • показывает некоторые пользовательские трюки для показа/скрытия определенного пользовательского интерфейса части, основанные на ролях, например: <h1 *jhiHasAnyAuthority="'ROLE_ADMIN'">Hello, admin user</h1>, который вы можете легко принять в свой собственный вариант использования.
  • у вас может быть рабочий проект примерно за 2 минуты: идеально подходит для обучения (перейдите к самому простому monolithic web application!)

Ответ 2

На ваш вопрос нет единого ответа. Все зависит от структуры проекта. Если между упомянутыми вами ролями много общего, тогда лучше использовать один index.jsp для всех ролей. Тогда вам не нужно дублировать общую логику (библиотеки js и css, настраиваемые общие сценарии, представления и стили). Если между ролями мало общего, тогда лучше иметь отдельные файлы index.jsp для каждой роли, так как один файл index.jsp будет динамически создаваться во время выполнения программы в зависимости от выбранной роли (я думаю, что это все еще возможно для исправления путем кеширования).

В наших проектах мы используем подход с одним файлом index.jsp. Это связано прежде всего с тем, что у них много общей логики. Но в любом случае решение будет принято вами.

Кроме того, если вы используете Spring Security и можете добавлять новые роли в процессе разработки проекта, то подход @PreAuthorize ("hasRole ('ROLE_USER')") будет не очень хорошим. Потому что, если вы добавите новую роль в базу данных, вам придется добавить много кода в проект, чтобы предоставить этой новой роли требуемый доступ. Таким образом, в этом случае лучше предоставить доступ через разрешения. И создайте связь many to many между rolespermissions

Ответ 3

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

Пользователь 0..n --- 0..m Роль

Роль 0..n --- 0..m Привилегия

Производственный код

В вашем случае вы можете:

  • Admin не может просматривать, редактировать оценки учащихся.
  • Student может просматривать счет, но не может редактировать.
  • Professor может просматривать, редактировать, добавлять баллы.

Вы можете сделать следующее:

Роль

  • ROLE_SCORE_EDITOR
  • ROLE_SCORE_VIEWER

Privilege

  • OP_READ_SCORE
  • OP_CREATE_SCORE
  • OP_UPDATE_SCORE
  • OP_DELETE_SCORE --- > Наверное, не нужен этот, но достаточно для примера.

Роль - Привилегия

ROLE_SCORE_EDITOR

  • OP_READ_SCORE
  • OP_CREATE_SCORE
  • OP_UPDATE_SCORE

ROLE_SCORE_VIEWER

  • OP_READ_SCORE

User-Role

Администратор (это действительно зависит от вас, в моем случае я должен оставить его пустым)

Профессор

  • ROLE_SCORE_EDITOR

Studen

  • ROLE_SCORE_VIEWER

Затем в вашем шаблоне просто защитите свой вид с помощью user.hasPrivilege или user.hasRole. Он будет работать нормально.

P/s: Извините за мой плохой английский. Если вам что-то нужно, прокомментируйте ниже или прокомментируйте мой gist

Ответ 4

Вы можете создавать разные роли для доступа к различным запрещенным областям. Например, вы можете иметь роли ученика, профессора и администратора. Позже вы можете разрешить или запретить доступ к контенту на основе ролей. Spring Безопасность может быть вам полезна.

Ответ 5

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

Вы также можете использовать проверку безопасности Spring и проверку подлинности jdbc.

Ответ 6

Я сейчас в подобной ситуации. Мой проект нуждается в аутентификации и авторизации на основе ролей. Для приложений Java существует ряд решений. Наша команда решила использовать Keycloak, что является дополнительным приложением, в котором вы можете справиться с большей частью управления пользователями. Он может работать на отдельном сервере. Хотя, в зависимости от объема вашего приложения, это может быть излишним.

Как я вижу, вы еще не внедрили аутентификацию. Эта часть завершена в моем случае, и это было сделано главным образом через конфигурацию на веб-сервере Keycloak +.

Как правило, вы можете использовать защиту Java EE для авторизации на большинстве современных веб-серверов. Это позволит вам использовать аннотации, такие как @RolesAllowed, чтобы предоставлять или запрещать доступ и работать независимо от Keycloak. Примеры. Таким образом, вы можете сохранить единую структуру для всех своих разных ролей и только решить легитимность запроса непосредственно перед его исполнением.

Ответ 7

вы можете создать табличную структуру с именем like role_user на основе того, что вы можете выделить

разные роли

Ответ 9

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

Вот пример для начала: Spring безопасность - мир привет

В приведенном выше примере позвольте мне показать фрагмент кода, чтобы придать больше моего требования:

@Override
    protected void configure(HttpSecurity http) throws Exception {

      http.authorizeRequests()
        .antMatchers("/admin/**").access("hasRole('ROLE_ADMIN')")
        .antMatchers("/dba/**").access("hasRole('ROLE_ADMIN') or hasRole('ROLE_DBA')")
        .and().formLogin();

    }

Итак, что будет делать вышеуказанная конфигурация, когда вы пытаетесь получить доступ к странице /admin или любому URL-адресу под страницами администратора, например. /admin/profile, /admin/home и т.д., вас попросят подтвердить подлинность (с именем пользователя и паролем в вашем случае). Безопасность spring проверяет правильность имени пользователя и пароля. В дополнение к этому, он также проверит, имеет ли предоставленное имя пользователя роль администратора. Если оба (пароль и роль) проверяются успешно, тогда вам будет разрешен доступ только к этой странице.

Таким образом, всего несколькими строками кода вы контролируете всю безопасность с помощью управления ролью для своего приложения.

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

Ответ 10

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

Ответ 11

Лучший подход: Spring Безопасность

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

  • Скажите, что в вашей базе данных есть таблица пользователя. Добавьте имя столбца, например. USER_RIGHTS.
  • В вашем приложении этот столбец является полем вашего класса модели пользователя
  • Создайте метод, который проверяет это поле и обрабатывает роли по вашему желанию.

Например, если роль пользователя определяет, на каких страницах у них есть доступ, это упрощенный пример кода:

В начале вашей веб-страницы:

<h:body>

<f:metadata>
    <f:viewAction action="#{userService.checkIfLogged()}" />
    <f:viewAction action="#{userService.accessCheck('page 2')}" />
</f:metadata>

и в вашем методе bean:

@Override
@Transactional
public String accessCheck(String page) {
    try {
       HttpSession sess = Util.getSession();
       String user = sess.getAttribute("username").toString();
       Session session = this.sessionFactory.getCurrentSession();
       User logged = (User) session.createQuery("select u from User u where 
                     u.username = :logged").setParameter("logged", 
                                            user).uniqueResult();
       if (page.equals("page 1")) {
        if (logged.getRights().equals("simple")) {
            return "profile?faces-redirect=true";
        } 
        else {
            return "#";
        }
    }   ... etc.

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

Ответ 12

Вы можете использовать поле в своей БД, которое сохраняет роль, но вы можете прочитать об ACL и RBAC.

Ответ 14

Хороший вопрос. Фактически расширение этого - это полный модуль аутентификации Для вашего маленького футляра Лучшая версия - это общая страница.. В соответствии с ролью появятся требуемые текстовые поля или поля. Например, в случае роли Студент: предмет, номер рулона будет доступен. Но если Профессор войдет на ту же страницу, он может видеть дополнительные поля, такие как числа, посещаемость и т.д. Самое простое решение может быть:. Чтобы создать основную таблицу с именем, идентификатором, типом (с типом, будь то ученик/профессор/администратор и т.д.), и используйте этот ТИП в качестве решающего фактора для отображения полей.