Как обрабатывать аутентификацию / авторизацию пользователей в базе данных?

В настоящее время я работаю над веб-проектом с использованием JSF 2.0, Tomcat 7 и MongoDB. У меня большой вопрос, как обрабатывать управление сеансом и аутентификацию / авторизацию пользователей в базе данных.

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

  • create.xhtml -> только для авторизованных пользователей.
  • events.xhtml -> публично для всех.

Основная структура, которую я планирую:

  • Проверьте, требуется ли на странице авторизованный пользователь (например, create.xhtml)
  • Если да, проверьте, вошел ли пользователь в систему
  • Если пользователь не вошел в систему, перейдите к login.xhtml
  • В случае успешного входа вернитесь на запрошенную страницу
  • Сохраняйте информацию «Пользователь вошел в систему», пока пользователь не нажмет кнопку выхода. (там, я думаю, @SessionScoped вступает в игру)

Вопрос в том:

  1. Какой способ сделать это проще?
  2. Где мне использовать аннотацию @SessionScoped? В Create.java или LoginManager.java?
  3. Безопасность Spring выглядит довольно сложной для моей проблемы, действительно ли она мне нужна? если да, не могли бы вы немного объяснить, как эта реализация работает вместе с JSF 2.0 и Mongo DB?

authentication database authorization jsf jakarta-ee
person whizzkid    schedule 01.04.2012    source источник

Ответы (1)


arrow_upward
63
arrow_downward

Есть несколько вариантов. Что выбрать, полностью зависит от вас. Просто объективно взвесьте конкретные преимущества и недостатки, соответствующие вашей ситуации.

1. Используйте предоставленную Java EE аутентификацию, управляемую контейнером

Просто объявите <security-constraint> в web.xml, который относится к области безопасности, которая настроена в servletcontainer. Вы можете для своего веб-приложения указать шаблоны URL, которые следует проверять для входа в систему и / или ролей, например /secured/*, /app/*, /private/* и т. Д.

К сожалению, до появления Java EE 8 вам все еще нужно настраивать область безопасности в зависимости от контейнера сервлетов. Обычно это описывается в документации, относящейся к сервлету. В случае Tomcat 8 это ИНСТРУКЦИЯ по области. Например, область на основе базы данных, основанная на таблицах пользователей / ролей, описана в разделе JDBCRealm.

Начиная с Java EE 8, наконец, появится стандартный API, основанный на JSR-375 .

Преимущества:

  • Относительно быстрая и простая установка и использование.
  • Начиная с Java EE 8 наконец-то появился надежный и гибкий стандартный API.

Недостатки:

Смотрите также:

2. Создайте фильтр сервлетов

Это обеспечивает гораздо более детальный контроль, но вам нужно будет написать весь код самостоятельно, и вы действительно должны знать / понимать, как следует реализовать такой фильтр, чтобы избежать потенциальных дыр в безопасности. На стороне JSF вы можете, например, просто поместить вошедшего в систему пользователя в качестве атрибута сеанса с помощью sessionMap.put("user", user) и проверить в фильтре, если session.getAttribute("user") не null.

Преимущества:

  • Мелкозернистый контроль.
  • Полностью независимый от контейнера.

Недостатки:

  • Новое изобретение колеса; новые функции требуют большого количества кода.
  • Как начинающий, вы никогда не уверены, что ваш код на 100% надежен.

Смотрите также:

3. Адаптируйте стороннюю структуру.

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

Преимущества:

  • Мелкозернистый контроль.
  • Полностью независимый от контейнера.
  • Никаких изобретений колеса; минимум собственного кода.
  • Тщательно разработан и протестирован множеством пользователей, поэтому, скорее всего, он на 100% надежен.

Недостатки:

  • Некоторая кривая обучения.

Смотрите также:

person BalusC    schedule 01.04.2012
comment
Уважаемый @BalusC, я использую фильтр сервлетов, чтобы ограничить пользователей определенными представлениями (URL-адресами). Меня беспокоит производительность. Я использую простые шрифты, а иногда щелчок по кнопке или обновление элемента вызывает фильтр несколько раз (я думаю, из-за внутренних запросов ajax). Есть ли способ минимизировать или лучше обрабатывать такое количество обращений к фильтру? Дополнительная проблема заключается в том, что когда вместо перенаправления используется переадресация страницы, URL-адрес запроса, который получает фильтр, всегда один и тот же, что затрудняет ограничение пользователей. - person Cristian Arteaga; 16.02.2018
comment
@CristianArteaga: Фактически, это новый вопрос для stackoverflow. Если вы его разместите, я уверен, что вы получите ответ - person Kukeltje; 05.12.2018