Filter Chain

// Spring Security가 정의한 표준 인터페이스
public interface UserDetails {
    // 이 유저가 가진 권한 목록 (예: [ROLE_USER] 또는 [ROLE_ADMIN])
    Collection<? extends GrantedAuthority> getAuthorities();

    // 비밀번호 (BCrypt로 암호화된 것)
    String getPassword();

    // 유저 식별자 (우리는 username, 즉 아이디)
    String getUsername();

    // 계정 만료 여부 — false면 Security가 로그인 차단
    boolean isAccountNonExpired();

    // 계정 잠금 여부 — false면 로그인 차단
    boolean isAccountNonLocked();

    // 비밀번호 만료 여부 — false면 비밀번호 변경 요구
    boolean isCredentialsNonExpired();

    // 계정 활성화 여부 — false면 로그인 차단
    boolean isEnabled();
}
// 우리 프로젝트에서는 계정 상태 관리 기능 미구현 → 4개 boolean 전부 true 반환

// Spring Security가 유저를 로딩할 때 사용하는 표준 인터페이스
public interface UserDetailsService {
    // username으로 유저를 찾아서 UserDetails로 반환
    // 없으면 UsernameNotFoundException 던짐 (Security가 이걸 기대함)
    UserDetails loadUserByUsername(String username)
        throws UsernameNotFoundException;
}

// 우리가 만드는 CustomUserDetailsService가 이걸 implements
// JwtAuthenticationFilter에서:
//   String username = jwtUtil.getUsername(token);
//   UserDetails userDetails = customUserDetailsService.loadUserByUsername(username);
// Security 표준대로 호출하므로 나중에 구현체를 바꿔도 필터 코드는 그대로

// JwtAuthenticationFilter에서 (토큰 검증 성공 시)

// ① UserDetails 로딩 (DB 조회)
UserDetails userDetails =
    customUserDetailsService.loadUserByUsername(username);

// ② Authentication 객체 생성
//    (유저정보, null, 권한목록) — 3인자 생성자 → authenticated=true
UsernamePasswordAuthenticationToken authentication =
    new UsernamePasswordAuthenticationToken(
        userDetails,                   // principal
        null,                          // credentials (이미 검증됨)
        userDetails.getAuthorities()  // 권한 목록
    );

// ③ SecurityContext에 저장 ← 핵심!
//    이제부터 이 요청 처리 내내 이 인증 정보를 꺼낼 수 있음
SecurityContextHolder
    .getContext()
    .setAuthentication(authentication);

// ④ 다음 Filter로 넘김
filterChain.doFilter(request, response);

// ⑤ Controller에서 꺼내기
//    @AuthenticationPrincipal이 SecurityContext에서 principal을 자동으로 꺼냄
public ResponseEntity<?> write(...,
        @AuthenticationPrincipal CustomUserDetails userDetails) {
    // userDetails = 위의 ① CustomUserDetails 객체 그대로!
    userDetails.getUser(); // User 엔티티
}

// ===== 2차 방식 — request 속성에서 직접 꺼내기 =====
@PostMapping("/api/board/write")
public ResponseEntity<?> write(
        @RequestBody BoardDto boardDto,
        HttpServletRequest request) {  // request 받아야 함
    User loginUser = (User) request.getAttribute("loginUser"); // 꺼내기
    if (loginUser == null)                                   // null 체크 필수!
        return ResponseEntity.status(401).build();
    boardService.write(boardDto, loginUser);
    return ResponseEntity.ok(...);
}

// ===== 3차 방식 — @AuthenticationPrincipal로 자동 주입 =====
@PostMapping("/write")
public ResponseEntity<?> write(
        @RequestBody BoardDto boardDto,
        @AuthenticationPrincipal CustomUserDetails userDetails) { // 자동 주입!
    // null 체크 불필요: SecurityConfig에서 이미 인증 요구 설정함
    // SecurityConfig: .anyRequest().authenticated() → 미인증 시 Security가 먼저 차단
    boardService.write(boardDto, userDetails.getUser()); // User 엔티티 꺼내기
    return ResponseEntity.ok(Map.of("message", "글쓰기 성공"));
}

// @AuthenticationPrincipal 내부 동작:
// SecurityContext.getAuthentication().getPrincipal()
// → UsernamePasswordAuthenticationToken.principal
// → CustomUserDetails 객체 (JwtAuthenticationFilter에서 저장한 것)

// SecurityConfig에서 권한 설정
.requestMatchers("/api/admin/**").hasRole("ADMIN")
// hasRole("ADMIN") → 내부적으로 "ROLE_ADMIN"을 찾음
// "ROLE_" 접두사를 자동으로 붙여서 비교

.requestMatchers("/api/admin/**").hasAuthority("ROLE_ADMIN")
// hasAuthority("ROLE_ADMIN") → "ROLE_ADMIN"을 그대로 찾음
// ROLE_ 접두사 자동 추가 없음 — 있는 그대로 비교

// 우리 CustomUserDetails.getAuthorities():
return List.of(new SimpleGrantedAuthority(user.getRole()));
// user.getRole() = "ROLE_ADMIN" (DB에 ROLE_ 포함해서 저장)

// 따라서:
// hasRole("ADMIN")       → "ROLE_" + "ADMIN" = "ROLE_ADMIN" → ✅ 매칭
// hasAuthority("ROLE_ADMIN") → "ROLE_ADMIN" → ✅ 매칭 (둘 다 결과 같음)
// hasAuthority("ADMIN")  → "ADMIN" → ❌ 매칭 안됨! (ROLE_ 없으니)

// javax.servlet.Filter를 직접 구현하면:
public class MyFilter implements Filter {
    @Override
    public void doFilter(...) { ... }
    // 문제: 같은 요청에서 forward/include가 발생하면
    // 이 filter가 여러 번 실행될 수 있음 → JWT 검증 중복 실행 위험
}

// OncePerRequestFilter를 extends하면:
public class JwtAuthenticationFilter
        extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(...) { ... }
    // 같은 요청에서 무조건 딱 한 번만 실행 보장
    // JWT 검증은 요청당 1회만 해야 하므로 이게 안전함
}

// 이름 그대로: Once (한 번) Per Request (요청당) Filter