Small bug with ApplicationConfiguration.java, UserRepository

[kRichard32]

https://github.com/Erik-Cupsa/Spring-Security-Tutorial/blob/72ab4f1c582da4f5cb4b3d334d36f022a42df1d2/demo/src/main/java/com/example/demo/config/JwtAuthenticationFilter.java#L52C13-L64C57

this.userDetailsService.loadUserByUsername is called with a username (jwtService.extractUsername(jwt) extracts the username, not the email), and later UserDetails userDetails = this.userDetailsService.loadUserByUsername(userEmail); is called. This function comes from applicationConfiguration.java, where userDetailsService is implemented with userRepository.findByEmail(username). As emails aren't usernames, these functions cause a UsernameNotFoundException to be thrown when attempting to do any request to the server with valid authorization tokens.

If you change userRepository.findByEmail to userRepository.findByUsername in ApplicationConfiguration.java and add Optional<UserKoko> findByUsername(String username); in UserRepository.java, this problem is fixed, and the code works as intended.

Thanks!

[kRichard32]

Ah, after doing a bit more testing, due to how function

Spring-Security-Tutorial/demo/src/main/java/com/example/demo/controller/AuthenticationController.java

Line 33 in 72ab4f1

public ResponseEntity<LoginResponse> authenticate(@RequestBody LoginUserDto loginUserDto){

works, line 55 needs to be changed in order to provide a username, which means that the LoginUserDto object needs to have an additional username field. This is in addition to the above changes.

(Here's another bugfix I'm gonna add on, adding .cors(Customizer.withDefaults()) to the securityFilterChain in securityConfiguration.java fixes cors issues)