Читать на сайте alexkosarev.name/2023/06/03/authentication-entry-point-spring-security/ Читать в VK vk.com/@shurik.codes-tochki-vhoda-autentifikacii-spring-security Читать в Telegraph telegra.ph/Tochki-vhoda-autentifikacii---Spring-Security-06-03
Все супер! У меня предложение по тому, чтобы наглядно продемонстрировать на примере простого Spring Boot приложения как это все устроено, в связке с контроллерами, сервисами, репозиториями и так далее. Конкретно как зарегистрировать пользователя -> сохранить его логин и пароль в БД, при авторизации как правильно его аутентифицировать согласно полученных данных и данных в БД. Максимально абстрактно и с несложным примером)) В целом все понятно, но как это все в реальности связать правильно.....та еще задача.
Обьяснение отличное, спасибо. Но уж очень плохое название у класса выбрали авторы spring-security, когда видишь EntryPoint то кажется что это то с чего начинается цепочка фильтров, что то вроде AuthenticationManager. А по сути это то чем она заканчивается. Конечно после вашего объяснения становится понятно что это как бы начало аутентификации после её провала. Хотя может для англоговорящих это более очевидно.
Александр, спасибо! Так получилось, что долго пытался понять что и как делает exceptionHandling и authenticationEntryPoint и нафига оно вообще нужно ) - из просмотренных мной твое объяснение самое понятное и качественное. Респект! p.s. Вопрос - а как правильно поступить в случае с REST ? Отправить ответ "unathenticated" и в responceBody ссылку на endPoint для аутентификации?
Насчёт REST всё зависит от контракта между клиентским приложением и серверным. В целом на мой взгляд достаточно отправлять 401 Unauthorized для указания отсутствия аутентификации.
@@shurik_codes Спасибо за ответ! Александр, правильно ли я понимаю что exceptionHandling перехватывает исключения возникающие в процессе аутентификации и далее уже обработка идет в authenticationEntryPoint?
@@dmitrelkin9256 exceptionHandling перехватывает вообще все исключения, происходящие в процессе работы Spring Security, а в authenticationEntryPoint передаёт исключения AuthenticationException
Отлично!. А в чем принципиальное отличие, мы ведь можем вместо .authenticationEntryPoint указать кастомную точку аунтефикации через .loginPage("страница")?
HttpSecurity.exceptionHandling().authenticationEntryPoint() - это основной способ задания точки входа, а loginPage - это метод из DSL аутентификации при помощи формы, который в качестве точки входа использует new LoginUrlAuthenticationEntryPoint(loginPage), по сути упрощенный способ установить точку входа в контексте аутентификации при помощи формы.
Александр, ваши ролики - это просто клад. У меня возник один вопросик. Когда вы поставили точку входа в "sign-in.html", я так понимаю у вас уже был реализован контроллер логирования? Или он должен по дефолту работать?
Я хочу, чтобы пользователю при неправильном вводе логина/пароля показывался шаблон Thymleaf с атрибутом (Model) incorrectUsernameOrPassword. Скажите, пожалуйста, как это можно сделать? Другими словами, я хочу узнать, как показать пользователю страницу, динамично созданную с помощью Thymleaf и не использовать sendRedirect.
Вариантов много, самый простой - при загрузке информации о пользователе при помощи UserDetailsService указывать, что пользователь заблокирован. Но можно реализовать и свой вариант при помощи фильтра, который будет проверять после аутентификации, заблокирован пользователь или нет и перенаправлять его на соответствующую страницу.
Читать на сайте alexkosarev.name/2023/06/03/authentication-entry-point-spring-security/
Читать в VK vk.com/@shurik.codes-tochki-vhoda-autentifikacii-spring-security
Читать в Telegraph telegra.ph/Tochki-vhoda-autentifikacii---Spring-Security-06-03
Все супер! У меня предложение по тому, чтобы наглядно продемонстрировать на примере простого Spring Boot приложения как это все устроено, в связке с контроллерами, сервисами, репозиториями и так далее. Конкретно как зарегистрировать пользователя -> сохранить его логин и пароль в БД, при авторизации как правильно его аутентифицировать согласно полученных данных и данных в БД. Максимально абстрактно и с несложным примером)) В целом все понятно, но как это все в реальности связать правильно.....та еще задача.
Учту, у меня есть в планах такой ролик
Обьяснение отличное, спасибо. Но уж очень плохое название у класса выбрали авторы spring-security, когда видишь EntryPoint то кажется что это то с чего начинается цепочка фильтров, что то вроде AuthenticationManager. А по сути это то чем она заканчивается. Конечно после вашего объяснения становится понятно что это как бы начало аутентификации после её провала.
Хотя может для англоговорящих это более очевидно.
Александр, спасибо! Так получилось, что долго пытался понять что и как делает exceptionHandling и authenticationEntryPoint и нафига оно вообще нужно ) - из просмотренных мной твое объяснение самое понятное и качественное. Респект!
p.s. Вопрос - а как правильно поступить в случае с REST ? Отправить ответ "unathenticated" и в responceBody ссылку на endPoint для аутентификации?
Насчёт REST всё зависит от контракта между клиентским приложением и серверным. В целом на мой взгляд достаточно отправлять 401 Unauthorized для указания отсутствия аутентификации.
@@shurik_codes Спасибо за ответ! Александр, правильно ли я понимаю что exceptionHandling перехватывает исключения возникающие в процессе аутентификации и далее уже обработка идет в authenticationEntryPoint?
@@dmitrelkin9256 exceptionHandling перехватывает вообще все исключения, происходящие в процессе работы Spring Security, а в authenticationEntryPoint передаёт исключения AuthenticationException
Отлично!. А в чем принципиальное отличие, мы ведь можем вместо .authenticationEntryPoint указать кастомную точку аунтефикации через .loginPage("страница")?
HttpSecurity.exceptionHandling().authenticationEntryPoint() - это основной способ задания точки входа, а loginPage - это метод из DSL аутентификации при помощи формы, который в качестве точки входа использует new LoginUrlAuthenticationEntryPoint(loginPage), по сути упрощенный способ установить точку входа в контексте аутентификации при помощи формы.
Александр, ваши ролики - это просто клад. У меня возник один вопросик. Когда вы поставили точку входа в "sign-in.html", я так понимаю у вас уже был реализован контроллер логирования? Или он должен по дефолту работать?
И как вы авторизовались, используя пароль password, а не сгенерированный?
Фильтр для логина автоматически активируется при использовании formLogin при конфигурировании цепочки фильтров безопасности
@@karton2282 задал в application.yml постоянный пароль свойством spring.security.user.password
@@shurik_codes Надеюсь у вас в планах есть сделать ролик про аутентификации с использованием JWT токена)
Планы на аутентификацию при помощи JWT у меня есть
Круто, спасибо за контент!
Заметил swagger asterisk-a, занимаетесь звонками?
Немного)
Кастомный dsl в 7-ом Spring Security похоже удалят, на 6.1 большинство chain-методов помечены как deprecated, форсят использование lamda выражений
Вот это поворот, пора обновляться до spring boot 3.1, судя по всему там много интересного
@@shurik_codes да, депрекейтов накинули будь здоров)
Я хочу, чтобы пользователю при неправильном вводе логина/пароля показывался шаблон Thymleaf с атрибутом (Model) incorrectUsernameOrPassword. Скажите, пожалуйста, как это можно сделать? Другими словами, я хочу узнать, как показать пользователю страницу, динамично созданную с помощью Thymleaf и не использовать sendRedirect.
А если я хочу jdbc сессию, но при этом REST API, какая точка входа должна быть?
Точка входа зависит от используемого способа аутентификации, так что она может быть любой.
Подскажите пожалуйста, а как обработывать ошибку входа если пользователь в "бане". Перенаправлять на страницу с сообщением о бане?
Вариантов много, самый простой - при загрузке информации о пользователе при помощи UserDetailsService указывать, что пользователь заблокирован. Но можно реализовать и свой вариант при помощи фильтра, который будет проверять после аутентификации, заблокирован пользователь или нет и перенаправлять его на соответствующую страницу.
Добрый день, планируется ли материал по jwt авторизации?
Надеюсь, до неё тоже дойдёт)
Спасибо, ждем новые видо