시큐리티 필터 체인

Yeeun·2025년 5월 21일
스프링부트
0

SpringBoot

목록 보기
39/46

시큐리티 필터 체인 관련해서 , 필터체인프록시는 톰캣이 관리하는 서블릿컨테이너에 올라가고 시큐리티 필터는 프록시에 의해 실행되는데 이건 ioc(스프링부트)에 올라간다

p421

시큐리티 필터체인을 내가 @Congifuration 등록하면 UsernamepasswardAuthentication 이건 기본필터가 아니라 사라짐. 그래서 http.formLogin(form -> 이런식으로 내가 설정해줘야함.

복습 (342/426) 책 408~
자바, 어플리케이션 프로퍼티는 다시타이핑 / html은 그냥복사

프로젝트만들기 (7-1) / 시큐리티 디펜던시는 걍 추가하기
패스워드 콘솔창에뜨는지확인
헬로우 html만들고 로그인하면 화면뜨는지보고
데이터 서정들하고
시큐리티 필터체인 등록해보기. (JDBC 연동 시큐리티는 건너뛰기)

유저로 로그인하니 static / main / resource 아래 hello.html 이 자동실행될 줄 알았는데 아님
http://localhost:8080/hello.html 검색해야 됨
로그인하면 자동 리다이렉트 되게 하려면 루트가 이거라고 컨피그 명시해주거나 그래야함

아무튼 , 로그인하고 링크치고 들어가보고 localhost:8080/logout 로그아웃 하고 다시 링크쳐보면 접속안됨 확인 .

SecurityFilterChain을 직접 정의하게 되면, Spring Security의 기본 설정이 모두 비활성화됨
즉, 로그인 페이지도 더 이상 자동으로 제공되지 않음. 기본필터를 제외하곤 내가 등록해서 써야되므로 , 로그인페이지가 이젠 안뜸. 이미 만들어진 로그인 페이지 ( 아까 유저네임패스워드어뗀티케이션이 제공해준)를 쓰고싶다면

이렇게 로그인 메소드를 넣어주고 ,
내가 만든 메소드로 매핑하여 넣을 수 있음. 현재는 겟방식으로 주소창에 / 치고 전달하는 방식으로 사용중인데, 내가 메소드 만들면 포스트방식으로 전달되니 포스트매핑해야함.

컨트롤러 작성하여 루트 겟매핑 만들어주기. 어플리케이션 프로퍼티에 /WEB-INF/board 프리픽스 서픽스 설정 해뒀으니 그냥 스트링만 리턴해도 자동으로 웹인포 아래 jsp 호출되는게 보통이지만, 타임리프 디펜던시가 있어 타임리프가 우선권을 가짐

1.pom.xml에 Thymeleaf 의존성이 있으면 .html이 .jsp보다 우선 처리됨
2./templates/ 아래 .html을 우선 찾음
3.devtools 사용 중에도 반영 안 될 땐 → 완전히 재실행 필요

h2 서버 켜져있어야 함. 안그러면 콘솔에 커넥션 브로큰 오류남


spring.datasource.username=sa
spring.datasource.password=abcd
아이디랑 패스워드 프로퍼티에 등록했기에 자동로그인됨.

근데 롤 지정 안했는데도 유알엘로 매니저, 어드민 등의 페이지가 호출이 안됨

어노테이션을 컨트롤러가 아니라 컨피큐레이션으로 설정해서 그랬던거. 수정함 / 작동됨

기본 로그인 페이지를 쓰지 않고, /login 경로로 직접 GET 요청이 오면 HTML을 보여주겠다

이렇게 직접 inMemoryAuthentication()을 설정하면,
application.properties에 설정한

spring.security.user.name, spring.security.user.password는 무시됨

UserDetailsService 를 왜 상속해서 BoardUserDetailsService 를 만드는가?

스프링 시큐리티는 유저디테일즈객체타입만 인지하기에 , 어떤 디비든 객체를 이 타입으로 돌려주기위해 인터페이스 상속받은것

Member implements UserDetails를 안 쓰고 BoardUserDetailsService에서 변환하는 이유

  1. 역할 분리 원칙 (Separation of Concerns)
    Member 클래스는 순수한 데이터 객체(Entity)로써 DB 매핑에만 집중하게 하고,

Spring Security의 UserDetails 인터페이스와 같은 보안 로직은 따로 관리하겠다는 의도예요.

  1. 유연성과 재사용성
    나중에 Member 구조가 바뀌거나 UserDetails 구현 방식이 바뀌어도
    BoardUserDetailsService만 수정하면 되고,
    도메인 객체인 Member는 그대로 유지할 수 있어요.

  2. 보안과 DB 계층의 분리
    UserDetails는 보안 로직 관련 인터페이스이므로,
    도메인 객체(Member)와 직접적으로 결합시키면
    보안 계층과 데이터 계층이 얽히게 되어 유지보수가 어려워질 수 있어요.

  3. 테스트와 디버깅이 쉬워짐
    BoardUserDetailsService만 단위 테스트하거나 모킹(mock)해서
    보안 인증 처리 로직만 독립적으로 검증할 수 있어요.

User 클래스란?
Spring Security가 내부적으로 사용하는 UserDetails 구현 클래스입니다.

생성자에 username, password, 권한(Role) 등을 넣어서 UserDetails 객체로 쉽게 만들 수 있게 도와줘요. 당신이 만든 Member는 그냥 JPA Entity니까, 이걸 Spring Security가 이해할 수 있는 UserDetails로 바꾸기 위해 User 클래스를 상속받는 거예요.

Member(내 데이터) → SecurityUser(User 상속) → Spring Security가 처리 가능

BoardUserDetailsService가 실제로 UserDetails 객체로 바꿔주는 역할을 합니다.
하지만 그 내부에서 바로 UserDetails를 생성해야 하니까,
Spring이 제공하는 User 클래스를 빌려서 그 작업을 간단히 처리하는 거예요.

과정

DB에서 Member를 꺼냄
→ BoardUserDetailsService.loadUserByUsername() 메서드에서 수행

꺼낸 Member 객체를 Spring Security가 이해할 수 있는 UserDetails 객체로 변환
→ 이 변환 작업을 쉽게 하기 위해 Member 정보를 담은 User 객체 생성
→ 또는 User를 상속한 SecurityMember 클래스를 만들어 사용

리턴
→ loadUserByUsername()는 반드시 UserDetails 타입을 반환해야 하므로
변환된 객체(User 또는 상속한 클래스)를 return


passward라고 오타나서 게터가 안먹었음.

member.getPassword() 같은 메서드를 호출하려면, Member 클래스에 getPassword()라는 getter 메서드가 있어야 합니다.

유저디테일즈객체로 변환하는게 BoardUserDetailsService 이게 아니라 SecurityUser 이거란거고 , 보드유저디테일즈는 서비스객체인거

역할 구분

클래스명역할
SecurityUser (또는 SecurityMember)UserDetails를 구현한 클래스, 실제로 스프링 시큐리티가 인식하는 사용자 정보 객체로 변환하는 역할 수행
BoardUserDetailsServiceUserDetailsService 인터페이스 구현체로, DB에서 Member 데이터를 조회하고, SecurityUser 객체로 변환해 반환하는 서비스 계층 역할

흐름

  1. 로그인 시, 스프링 시큐리티가 BoardUserDetailsService.loadUserByUsername() 호출
  2. BoardUserDetailsService는 DB에서 Member 조회
  3. 조회한 Member 객체를 SecurityUser (UserDetails 구현체)로 변환 후 리턴
  4. 스프링 시큐리티는 SecurityUser 객체를 사용해 인증/권한 처리

간단 코드 예시

public class SecurityUser extends User {
    public SecurityUser(Member member) {
        super(member.getId(), member.getPassword(), AuthorityUtils.createAuthorityList(member.getRole().toString()));
    }
}

@Service
public class BoardUserDetailsService implements UserDetailsService {
    @Autowired
    private MemberRepository memberRepo;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        Member member = memberRepo.findById(username)
                        .orElseThrow(() -> new UsernameNotFoundException("사용자 없음"));

        return new SecurityUser(member);
    }
}

결론

  • SecurityUser는 UserDetails 객체
  • BoardUserDetailsService는 UserDetails를 생성하고 반환하는 서비스

그래서 유저 정보를 실제로 감싸는(포장하는) 건 SecurityUser고,
DB 조회 및 변환 흐름을 처리하는 건 BoardUserDetailsService입니다.

세션에서 로그인된 유저정보 ( 유저클래스, 유저디테일즈인터페이스 구현된 객체 ) 를 저장하고 계쏙쓰는 형태.

실제프로젝트에선 세션을 유지하는 방식을 안쓰고 , 프론트에서 뭔가 요청했을때 지금은 세션이 유지된상태니 세션에서 뒤져보고 응답하고 그런형태지만 jwt방식은 세션이 없고 ( 존재하긴하지만 시큐리티에서 필요한정보가없음) 접속하면 필터서 유저객체를만들어 세션에 등록하고, 리턴하며 세션을 삭제함. 톰캣에서 사용하는 세션은 유지되지만, 그 안의 시큐리티서 사용하는 로그인정보와 관련된건 유지를 하지 않음. 세션스테이트리스.
인증필터, 인가필터 를 jwt방식에선 우리가 만들어줘야함. 그걸알면 토큰방식끝.

profile
Yeeun
이전 포스트

스프링 시큐리티 420p

다음 포스트

스프링부트 jwt

0개의 댓글