Основная HTTP-аутентификация с помощью приложения Postman [дубликат]
Загрузить gerrit
java -jar gerrit-full-2.5.2.war init
Следуйте инструкциям.
Для целей тестирования используйте метод development_become_any_account при аутентификации.
, тогда вы закончите с работающим сервером
1 ответ
, как он выглядит в SecurityContextHolder.getContext (). getAuthentication (); это означает, что клиент уже имеет cookie JSESSION, поэтому он уже аутентифицирован с именем пользователя и паролем.
Проверка пароля еще раз сделает этот метод бесполезным, поскольку он приведет к повторному завершению процесса аутентификации (получение пароль из базы данных, сравните его ...), и я думаю, это было написано, чтобы избежать этого. Кроме того, пароль не хранится в контексте SecurityContextHolder
В случае атаки CRSF может возникнуть потенциальное нарушение безопасности, но spring-security обеспечивает защиту от этого. см. spring-security csrf
-
1Спасибо за информацию, я проверил то же самое. Я использовал Postman для тестирования API REST и ожидал 401, если я передаю неправильный пароль с тем же пользователем. Поскольку ранее я предоставлял правильный пароль в более раннем запросе теста, новый запрос с неправильным pwd также передавался. – dev. K 18 April 2018 в 11:13
-
2@ dev.K несколько месяцев назад я написал сообщение о проверке подлинности saml и аутентификации jwt для REST API. Самл не относится к вам здесь, но вы можете взглянуть на часть jwt: sylvainlemoine.com/2016/06/06/… . Кроме того, официальная документация по весне - обязательное чтение. – slemoine 18 April 2018 в 12:33
-
3@ dev.K, как указано в dur, вы можете установить защиту для отключения сеанса с состоянием и csrf, например: http .sessionManagement (). sessionCreationPolicy (SessionCreationPolicy.STATELESS) .and (). csrf (). disable () – slemoine 18 April 2018 в 12:36
-
4Спасибо slemoine и dur за объяснение, поскольку указанная конфигурация получила ожидаемое поведение, протестированное через почтальона. – dev. K 18 April 2018 в 13:49