After writing the websecurityconfig class that inherits the websecurityconfigureradapter class, we need to define authentication in the configure (authentication manager builder auth) method, which is used to obtain information sources and password verification rules. (the name of the configure function doesn’t matter. The official name seems to be configureglobal (…) ）It is important to configure the authenticationmanagerbuilder in the class annotated by @ enablewebsecurity or @ enableglobalmethodsecurity or @ enableglobalauthentication).
The source of authentication information I used at the beginning was in memory authentication. The code is as follows
protected void configure (authentication manager auth) throws exception { // inmemoryauthentication gets from memory auth.inMemoryAuthentication ().withUser("user1").password("123456").roles("USER"); } The login page of spring security is used. As a result, when logging in, the user name and password are correct, and the resource cannot be opened, so it still stays on the login page. There is no passwordencoder mapped for the ID "null".
Baidu found that this is because spring security 5.0 added a variety of encryption methods, but also changed the password format.
Let's take a look at the official documents. Here are the original words of the official documents:
-------------------------------------------------------------------------------------------------------------------
The general format for a password is:
{id}encodedPassword
Such that id is an identifier used to look up which PasswordEncoder should be used and encodedPassword is the original encoded password for the selected PasswordEncoder. The id must be at the beginning of the password, start with { and end with }. If the id cannot be found, the id will be null. For example, the following might be a list of passwords encoded using different id. All of the original passwords are "password".
{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
{noop}password
{pbkdf2}5d923b44a6d129f3ddf3e3c8d29412723dcbde72445e8ef6bf3b508fbf17fa4ed4d6b99ca763d8dc
{scrypt}$e0801$8bWJaSu2IKSn9Z9kM+TPXfOc/9bdYSrN1oD9qfVThWEwdRTnO7re7Ei+fUZRJ68k9lTyuTeUp4of4g24hHnazw==$OAOec05+bXxvuu/1qZ6NUR+xQYvYv7BeL1QxwRpY5Pc=
{sha256}97cde38028ad898ebc02e690819fa220e88c62e0699403e94fff291cfffaf8410849f27605abcbc0
-------------------------------------------------------------------------------------------------------------------
The storage format of passwords in spring security is "{ID}.....". The front ID is the encryption method, the ID can be bcrypt, sha256, etc., followed by the encrypted password. In other words, when the program gets the passed password, it will first find the ID included by "{" and "}" to determine how the subsequent password is encrypted. If it cannot be found, it will be considered that the ID is null. This is why our program will report an error: there is no passwordencoder mapped for the ID "null". In the example of official documents, various encryption methods are used to encrypt the same password. The original password is "password".
If we want our project to log in normally, we need to modify the code in configure. We need to encrypt the password from the front end in some way. Spring security officially recommends using bcrypt encryption. So how to encrypt the password?Just specify it in the configure method.
After modification, it looks like this:
protected void configure (authentication manager auth) throws exception { // inmemoryauthentication gets from memory auth.inMemoryAuthentication ().passwordEncoder(new BCryptPasswordEncoder()).withUser("user1").password(new BCryptPasswordEncoder().encode("123456")).roles("USER"); } After inmemoryauthentication(), there is ". Passwordencoder (New bcryptpasswordencoder())", which is equivalent to using bcrypt encryption to process the user password when logging in. The previous ". Password (" 123456 ")" is changed to ". Password (New bcryptpasswordencoder(). Encode (" 123456 ")", which is equivalent to bcrypt encoding and encryption of the password in memory. The comparison is consistent, which indicates that the password is correct and login is allowed.
If you are also using the password from the memory, then according to the above modification should be successful login, no problem.
If you use to store the user name and password in the database, you usually use bcrypt code to encrypt the user password and store it in the database. And modify the configure() method, add ". Passwordencoder (New bcryptpasswordencoder())" to ensure that users use bcrypt to process the password when they log in, and then compare it with the password in the database. As follows:
// inject the implementation class of userdetailsservice auth.userDetailsService (userService).passwordEncoder(new BCryptPasswordEncoder());
reprint https://blog.csdn.net/canon_ in_ d_ major/article/details/79675033
in idea