Я очень новичок в безопасности Java Spring и следил за Spring.io учебное руководство.
В рамках этого я отредактировал класс WebSecurityConfig по мере необходимости:
@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/", "/home").permitAll()
.anyRequest().authenticated()
.and()
.formLogin()
.loginPage("/login")
.permitAll()
.and()
.logout()
.permitAll();
}
@Bean
@Override
public UserDetailsService userDetailsService() {
UserDetails user =
User.withDefaultPasswordEncoder()
.username("user")
.password("password")
.roles("USER")
.build();
return new InMemoryUserDetailsManager(user);
}
}
В методе userDetailService() он использует withDefaultPasswordEncoder(), который теперь устарел, как показано в документации: withDefaultPasswordEncoder ()
К сожалению, мне не удалось найти альтернативу этому, чтобы завершить это руководство без использования устаревшего метода. Может ли кто-нибудь предоставить этому альтернативу, если это возможно?
Спасибо!
Примечание: Я приложил пару снимков экрана с моей ошибкой, а также мой файл gradle


Я сделал, но при реализации этого (без простого извлечения репозитория), когда я писал метод, я продолжал получать сообщение об ошибке, в котором говорилось, что withDefaultPasswordEncoder () не может быть разрешено, и не позволяет мне запускать программу
Есть разница между устаревшим (вы получите предупреждение) и неразрешенным, что является ошибкой. Эта документация все еще находится в документации 5.0, поэтому ее не следует пропустить; какую версию зависимости Spring Security вы используете?
Используя gradle, который, как я полагаю, это 5.0.4.RELEASE ..... -> compile ("org.springframework.boot: spring-boot-starter-securi ty")
Spring Boot 1.5 или 2.0?
пружинный пыльник 1.5




Обновлено: удалил старый ответ, неправильно понял вопрос. Вот новый:
User.withDefaultPasswordEncoder() по-прежнему можно использовать для демонстраций, вам не нужно беспокоиться, если это то, что вы делаете - даже если он устарел - но в производстве у вас не должно быть простого текстового пароля в исходном коде.
Вместо того, чтобы использовать текущий метод userDetailsService(), вам следует использовать следующий:
private static final String ENCODED_PASSWORD = "$2a$10$AIUufK8g6EFhBcumRRV2L.AQNz3Bjp7oDQVFiO5JJMBFZQ6x2/R/2";
@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
auth.inMemoryAuthentication()
.passwordEncoder(passwordEncoder())
.withUser("user").password(ENCODED_PASSWORD).roles("USER");
}
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
Где ENCODED_PASSWORD - это secret123, закодированный с помощью BCrypt. Вы также можете кодировать его программно, например, так: passwordEncoder().encode("secret123").
Таким образом, даже если вы отправите свой код в общедоступный репозиторий, люди не узнают пароль, потому что ENCODED_PASSWORD показывает только закодированную версию пароля, а не текстовую версию, а потому, что вы знаете, что $2a$10$AIUufK8g6EFhBcumRRV2L.AQNz3Bjp7oDQVFiO5JJMBFZQ6x2/R/2 на самом деле является закодированным паролем для строка secret123, в то время как другие этого не делают, ваш пользователь в памяти с учетными данными user:secret123 не будет скомпрометирован.
Обратите внимание, что я использую оставить его в статической переменной для примера.
Привет, пожалуйста, быстрый вопрос о предложении passwordEncoder().encode("secret123"). Вы сказали Таким образом, даже если вы отправите свой код в общедоступный репозиторий, люди не узнают пароль, потому что ENCODED_PASSWORD показывает только закодированную версию пароля, а не текстовую версию., я запутался, если я использую passwordEncoder().encode("secret123") и загружу его в репозиторий, люди не увидят мой пароль? тогда как если я буду придерживаться вашего исходного кода, используя переменную ENCODED_PASSWORD, люди не увидят мой необработанный пароль. Я не понимаю, что вы имели в виду под Сюда,..., спасибо
@Scaramouche Никогда не стоит размещать свой пароль в публичном репозитории, независимо от того, закодирован он / хеширован или нет, но дело в том, что если вы вместо того, чтобы писать passwordEncoder().encode("secret123") в своем коде, вы нажали $2a$10$AIUufK8g6EFhBcumRRV2L.AQNz3Bjp7oDQVFiO5JJMBFZQ6x2/R/2, люди не стали бы автоматически узнает, что ваш пароль - secret123, потому что вы только что нажали хэш, а не фактический пароль. Я пытался сказать, что вы можете запустить System.out.println(passwordEncoder().encode("secret123")) локально, скопировать результат и использовать этот результат в качестве пароля.
... в вашем коде. Но опять же, имейте в виду, что все, что я говорю, это то, что продвижение $2a$10$AIUufK8g6EFhBcumRRV2L.AQNz3Bjp7oDQVFiO5JJMBFZQ6x2/R/2 намного безопаснее, чем продвижение passwordEncoder().encode("secret123"), если вы хотите скрыть свой пароль, но в будущем, когда появятся лучшие и более быстрые компьютеры, это очень вероятно для ваш пароль будет скомпрометирован. Лучше избегать размещения любых паролей / конфиденциальной информации в общедоступном репозитории. Вместо этого вы должны использовать переменные среды.
@Twin Как я могу справиться с успешной аутентификацией? Например, мне нужно сгенерировать токен GWT, вернуть его и добавить в HTTP-запрос в качестве нового заголовка. Является ли это возможным?
@TwiN Я последовал твоему подходу. Однако я продолжаю получать сообщение «Неверные учетные данные» при вводе имени пользователя как «пользователь» и пароля как «секрет123». Не могли бы вы помочь, почему возникает эта ошибка?
Использование passwordEncoder.encode () будет таким
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(AuthenticationManagerBuilder auth) throws Exception {
auth.inMemoryAuthentication()
.passwordEncoder(passwordEncoder())
.withUser("user")
.password(passwordEncoder().encode("miClave"))
.roles("USER");
}
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
}
Вы прочитали весь Javadoc? Он входит в существенные детали, особенно включая "приемлемо для демонстрации и начала работы".