Лучший подход для обработки входа и авторизации в Vaddin Flow?

Question

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

У меня есть вид входа в систему и главное приложение. просмотр с держателем контента для вложенных макетов.

Как проверить, вошел ли пользователь в систему и какие права он должен видеть или не видеть какую-то часть приложения? Я читал о BeforeEnterEvent и ReRouting, но все же это не очень понятно.

• Нужно ли использовать BeforeEnterEvent для каждого моего класса? Нужно ли создавать класс с пользовательскими параметрами, такими как логическое значение, чтобы проверить, вошел ли он в систему, и строку для вида авторизации, который у него есть? И где мне создать или сохранить этот экземпляр?

• Есть ли простой способ сделать это? Хотелось бы начать с пустого макета и начать с экрана входа в систему, а затем экран входа в систему решает поменяться основным видом приложения? И как мне запретить пользователю вводить адрес основного вида в панели и получать доступ к частям, к которым он не должен иметь доступ, например: / app / adminsettings

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

Answer 1

Как всегда, серебряных пуль нет. «Лучший способ» всегда зависит от требований и ваших возможностей: от Basi c Auth до какого-либо внешнего OID C провайдера.

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

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

• Имейте в виду, что при использовании библиотеки безопасности она имеет или допускает центрирование веб-пути c подход, что вы должны использовать его только для root и открыть пути к ресурсам и т. Д. c. API истории может выглядеть только так, как будто вы извлекаете URL-адреса с сервера, или веб-сокеты могут использоваться скрытно, и внезапно эти правила больше не применяются.

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

• Обычно имеется некоторая начальная «декларативная» часть безопасности (может ли пользователь даже войти в это представление; это обычно означает некоторое простое проверка ролей). Хорошим местом для проверки является BeforeEnterListener, добавленный к UI ; он будет называться перед любой навигацией к любому представлению . См. livecyle навигации

• Следующими точками входа, которые нужно охранять, являются BeforeEnterEvent, которые вы можете прослушивать в самом представлении и / или, возможно, оно реализует HasUrlParameter. Если вы берете параметры из «запроса» или пути, обычно это означает дальнейшие проверки (например, разрешено ли действующему пользователю редактировать запись в блоге с идентификатором 42). См. параметры маршрутизации и URL-адреса , а также livecyle навигации .

• Вглубь приложения вы получаете что-то более необходимое, что библиотеки часто делают кажутся декларативными, потому что они генерируют некоторый код для вас из некоторой аннотации (например, некоторый AOP, который генерирует код вокруг вашего @SecurityCheck('${u.owner}==${currentUser}') void save(User u) метода, который проверяет роль и принадлежит ли User u действующему пользователю).

  Будьте уверены, что ваш Io C system / library / ... видит эти аннотации и генерирует соответствующий код. Только @Route, например, получит полную обработку DI с помощью Vaadin + Spring - в остальном, ваша работа заключается в том, чтобы DI-инфраструктура могла выполнить свою работу (NPE из пропущенного @Autowired обнаруживается очень быстро, но проверка безопасности не будучи призванным, нет). Очевидный способ обойти это, это быть императивом и писать код самостоятельно, а не полагаться на то, что он будет там.

• Если у вас есть анонимная система, а затем какой-то логин, убедитесь, что отправлять пользователей на сеанс fre sh (и для этого UI); он не только предотвращает атаку с фиксацией сеанса, но также позволяет вам поместить все настройки маршрута и производные пользовательского интерфейса в соответствии с безопасностью в одном месте в начале создания пользовательского интерфейса. Если у вас есть состояние, которое вы хотите перенести, сделайте его частью URL-адреса, который ваш успешный процесс входа в систему отправит обратно или оставит в локальном хранилище браузера.