🔥 #10 스프링 시큐리티 로그인 진행

🔥 #8 에 이어서 진행~!

UserApiController를 보면, /auth/loginProc를 만들지 않았다.
왜냐하면 스프링 시큐리티가 가로채도록 할 것이기 때문이다.

가로채도록 하기 위해서는 SecurityConfig 의 configure 메소드에서 .loginProcessingUrl("/auth/loginProc") 를 추가해야 한다.

따라서, 현재 SecurityConfig는 아래처럼 작성하면 된다.

< SecurityConfig >

@Configuration // 빈 등록 (IoC관리)
@EnableWebSecurity // Security 필터가 등록됨 = 스프링 시큐리티가 이미 활성화는 되어있지만, 설정은 해당 파일에서 할 것임
@EnableGlobalMethodSecurity(prePostEnabled = true) // 특정 주소로 접근을 하면 권한 및 인증을 미리 체크 (수행한 후에 체크하는 것이 아님)
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    // 1. Bean 어노테이션은 메서드에 붙여서 객체 생성시 사용
    @Bean // IoC가 된다.
    public BCryptPasswordEncoder encodePWD() {
        return new BCryptPasswordEncoder(); // 이 객체를 스프링이 관리하게 됨. 필요할 때마다 가져가서 쓰면 된다.
    }

    // 필터링
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .csrf().disable() // csrf 토큰 비활성화 (테스트시 걸어두는게 좋음)
                .authorizeRequests() // request가 들어오면
                .antMatchers("/", "/auth/**", "/js/**", "/css/**", "/image/**") // 여기로 들어오면
                .permitAll() // 모두 가능 (누구나 가능)
                .anyRequest() // 그게 아닌 다른 모든 요청은
                .authenticated() // 인증이 되어야 한다
                .and()
                .formLogin()
                .loginPage("/auth/loginForm") // 인증이 필요한 요청은 이 로그인 폼으로 온다
                .loginProcessingUrl("/auth/loginProc") // 스프링 시큐리티가 해당 주소로 요청이 오는 로그인을 가로채서 대신 로그인을 한다.
                .defaultSuccessUrl("/"); // 로그인 성공하면 "/"로 간다.
//                .failureUrl("/fail"); // 실패시 url
    }

    // 참고 : .headers().frameOptions().disable() // 아이프레임 접근 막기
    // 참고 : .csrf().disable() // csrf 토큰 비활성화 (테스트시 걸어주는 것이 좋음)
}

---

스프링 시큐리티가 사용자가 요청한 username과 password를 가로채서 로그인을 하는데,
UserDetails 타입의 User 객체를 만들어야 한다.

왜냐하면 로그인을 진행하고 완료가 되면 스프링 시큐리티 세션에 유저 정보를 등록해야 하는데 User 객체를 등록할 수 없고, UserDetails 타입만 등록할 수 있기 때문이다.

< PrincipalDetail >

// 스프링 시큐리티가 로그인 요청을 가로채서 로그인을 진행하고 완료가 되면,
// UserDetails 타입의 오브젝트를 스프링 시큐리티의 고유한 세션 저장소에 저장한다.
public class PrincipalDetail implements UserDetails {
    private User user; // 콤포지션 (객체를 품고 있는 것)

    public PrincipalDetail(User user) {
        this.user = user;
    }

    @Override
    public String getPassword() {
        return user.getPassword();
    }

    @Override
    public String getUsername() {
        return user.getUsername();
    }

    // 계정이 만료되지 않았는지 리턴한다. (true : 만료 안됨)
    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    // 계정이 잠겨있는지 안 잠겨있는지 리턴한다. (true : 잠기지 않음)
    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    // 비밀번호가 만료되지 않았는지를 리턴한다. (true : 만료 안됨)
    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    // 계정이 활성화(사용가능)인지 리턴한다. (true : 활성화)
    @Override
    public boolean isEnabled() {
        return true;
    }

    // 계정이 갖고있는 권한 목록을 리턴한다. (권한이 여러개 있을 수 있어서 루프를 돌아야 하는데 현재는 하나만)
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {

        Collection<GrantedAuthority> collectors = new ArrayList<>(); // ArrayList는 Collection 타입이다. (상속)

//        collectors.add(new GrantedAuthority() {
//
//            @Override
//            public String getAuthority() {
//                return "ROLE_"+user.getRole(); // role 을 받을 때 앞에 "ROLE_" 붙이는 것(prefix)이 스프링의 규칙, 즉 ROLE_USER 같은 식으로 리턴됨
//            }
//        });

        collectors.add(()->{return "ROLE_"+ user.getRole();}); // 어차피 add 안에 들어갈 함수는 GrantedAuthority() 뿐이기 때문에 람다식으로 가능

        return collectors;
    }

}

세션에 PrincipalDetail를 저장하게 되는데, 그때 우리가 DB에 저장하는 User 객체도 포함되어 있어야 하기 때문에 컴포지션 한다.

타입은 UserDetails 이여야 하기 때문에 implements를 한다.
UserDetails가 들고 있는 추상 메서드들을 전부 오버라이딩 한다.

• 컴포지션 개념 ⬇

// 컴포지션
public class PrincipalDetail {
    private User user; // 콤포지션 (객체를 품고 있는 것) }
    
// 상속
public class PrincipalDetail extends User { }

- 상속 - 'IS-A' 관계
- 컴포지션 - 'HAS-A' 관계
- DI - ?????

'IS-A', 'HAS-A' 관계는 상속, 위임을 **정적인 클래스** 관계에서 설명하는 방식이다.
**DI**는 'HAS-A' 관계에서 **동적으로 대상 객체를 변경하는 방법**에 대한 것이다.

즉, 'HAS-A' 관계로 보면 인터페이스(추상 클래스)에 의존하도록 관계를 맺는 것까지 인데, DI는 여기에 추가해서 동적으로 인터페이스 구현 객체를 변경하는 방법까지를 이야기한다.

---

< PrincipalDetailService >

@Service // Bean 등록
public class PrincipalDetailService implements UserDetailsService {

    @Autowired
    private UserRepository userRepository;

    // 스프링이 로그인 요청을 가로챌 때, username과 password 변수 2개를 가로챔
    // password 처리는 스프링이 알아서 함
    // 나는 username이 해당 DB에 있는지만 확인해서 리턴해주면 됨
    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {

        User principal = userRepository.findByUsername(username) // Optional 타입이기 때문에 .orElseThrow
                .orElseThrow(()->{
                    return new UsernameNotFoundException("해당 사용자를 찾을 수 없습니다." + username);
                });

        return new PrincipalDetail(principal); // 이때 시큐리티 세션에 유저정보 저장됨
    }
}

상속받아 타입을 UserDetailService 로 한다.
오버라이딩한 loadUserByUsername 함수에서는 가로챈 username 변수가 DB에 있는지 확인한다.

그럼 이제 로그인이 요청될 때 loadUserByUsername 함수가 자동으로 실행되면서 username에 해당하는 User를 찾고 PrincipalDetail 타입(즉, UserDetails 타입)으로 리턴한다.
-> UserDetails 타입이 되었으므로 시큐리티의 세션에 유저 정보가 저장이 됨.

이 함수를 오버라이딩하여 구현해야한다. 그래야 우리의 진짜(?) User 정보를 담아서 리턴할 수 있다.

< UserRepository >

public interface UserRepository extends JpaRepository<User, Integer> {

    // SELECT * FROM user WHERE username = 1?;
    Optional<User> findByUsername(String username);
}

findByUsername 없어서 UserRepository에서 만들었다. (네이밍 규칙)

---

< SecurityConfig > 에 추가

    // 시큐리티가 대신 로그인 함 -> password 가로챔
    // 가로챈 password가 회원가입 될 때 무엇으로 해쉬가 되었는지 알아야함 -> 그래야 같은 해쉬로 암호화 하고 DB에 있는 해쉬와 비교하여 로그인
    // 즉, 패스워드 비교하는 메서드
    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(principalDetailService).passwordEncoder(encodePWD()); // passwordEncoder 하는 애가 encodePWD 임.
    }

여기서 로그인 한 password를 encode 해서 비교를 한다.

< SecurityConfig > 최종

@Configuration // 빈 등록 (IoC관리)
@EnableWebSecurity // Security 필터가 등록됨 = 스프링 시큐리티가 이미 활성화는 되어있지만, 설정은 해당 파일에서 할 것임
@EnableGlobalMethodSecurity(prePostEnabled = true) // 특정 주소로 접근을 하면 권한 및 인증을 미리 체크 (수행한 후에 체크하는 것이 아님)
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private PrincipalDetailService principalDetailService;

    // 1. Bean 어노테이션은 메서드에 붙여서 객체 생성시 사용
    @Bean // IoC가 된다.
    public BCryptPasswordEncoder encodePWD() {
        return new BCryptPasswordEncoder(); // 이 객체를 스프링이 관리하게 됨. 필요할 때마다 가져가서 쓰면 된다.
    }

    // 2. 시큐리티가 로그인할 때 어떤 암호화로 인코딩해서 비번을 비교할지 알려줘야 함.
    // 시큐리티가 대신 로그인 함 -> password 가로챔
    // 가로챈 password가 회원가입 될 때 무엇으로 해쉬가 되었는지 알아야함 -> 그래야 같은 해쉬로 암호화 하고 DB에 있는 해쉬와 비교하여 로그인
    // 즉, 패스워드 비교하는 메서드
    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(principalDetailService).passwordEncoder(encodePWD()); // passwordEncoder 하는 애가 encodePWD 임.
    }

    // 3. 필터링
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .csrf().disable() // csrf 토큰 비활성화 (테스트시 걸어두는게 좋음)
                .authorizeRequests() // request가 들어오면
                .antMatchers("/", "/auth/**", "/js/**", "/css/**", "/image/**") // 여기로 들어오면
                .permitAll() // 모두 가능 (누구나 가능)
                .anyRequest() // 그게 아닌 다른 모든 요청은
                .authenticated() // 인증이 되어야 한다
                .and()
                .formLogin()
                .loginPage("/auth/loginForm") // 인증이 필요한 요청은 이 로그인 폼으로 온다
                .loginProcessingUrl("/auth/loginProc") // 스프링 시큐리티가 해당 주소로 요청이 오는 로그인을 가로채서 대신 로그인을 한다.
                .defaultSuccessUrl("/"); // 로그인 성공하면 "/"로 간다.
//                .failureUrl("/fail"); // 실패시 url
    }

    // 참고 : .headers().frameOptions().disable() // 아이프레임 접근 막기
    // 참고 : .csrf().disable() // csrf 토큰 비활성화 (테스트시 걸어주는 것이 좋음)
}

---

위에까지 하면, 스프링 시큐리티 세션에 유저 정보가 저장된다.
우리가 UserDetail 타입으로 PrincipalDetail를 만들었으니 PrincipalDetail로 감싸서 저장될 것이다.

❓ 그러면 컨트롤러에서는 스프링 시큐리티가 만든 세션 정보를 어떻게 찾을까?

• 컨트롤러에서 로그인 된 세션을 찾는 방식 : @AuthenticationPrincipal PrincipalDetail principal

   @GetMapping({"", "/"})
    public String index(@AuthenticationPrincipal PrincipalDetail principal) { // 컨트롤러에서 로그인 된 세션을 찾는 방식 : @AuthenticationPrincipal PrincipalDetail principal
        // /WEB-INF/views/index.jsp
        System.out.println("로그인 사용자 아이디:"+principal.getUsername());
        return "index";
    }

위에 매개변수로 PrincipalDetail principal를 넣는 것은 되지만,
의존성 주입 방식으로 @Autowired private PrincipalDetail principal; 를 주입하는 것은 불가능하다.