HTTP 메소드는 클라이언트가 서버에 특정 동작을 요청할 때 사용하는 방식을 말합니다. 주요 메소드로는 GET, POST, PUT, PATCH, DELETE가 있고 추가적으로 HEAD, OPTIONS 등이 있습니다.
GET은 리소스를 조회할 때 사용하고, POST는 새로운 리소스를 생성할 때 씁니다. PUT은 리소스 전체를 수정하고, PATCH는 일부분만 수정할 때 사용합니다. DELETE는 리소스를 삭제합니다. HEAD는 GET과 비슷한데 헤더만 받아오고, OPTIONS는 서버가 지원하는 메소드를 확인할 때 사용합니다.
이런 메소드들은 RESTful API 설계에서 중요한 역할을 하는데, 각 메소드의 특성에 맞게 사용해야 합니다.
PUT 요청으로 "/character/{id}"가 들어오면, 이는 특정 캐릭터의 정보를 전체적으로 수정하는 기능을 수행할 것으로 짐작할 수 있습니다. PUT은 리소스 전체를 대체하는 메소드이기 때문입니다.
이런 요청에 대한 권한 체크는 크게 두 가지로 나눌 수 있습니다.
인증(Authentication) 확인: 요청한 사용자가 로그인되어 있는지 확인합니다. 주로 세션이나 JWT 같은 토큰을 사용합니다.
인가(Authorization) 확인: 로그인한 사용자가 해당 캐릭터를 수정할 권한이 있는지 확인합니다. 예를 들어:
사용자가 해당 캐릭터의 소유자인지 확인
사용자가 관리자 권한을 가지고 있는지 확인
특정 역할(예: 'CHARACTER_EDITOR')을 가지고 있는지 확인
리소스 존재 확인: {id}에 해당하는 캐릭터가 실제로 존재하는지 확인합니다.
권한이 확인되면 요청을 처리하고, 권한이 없다면 403 Forbidden 응답을, 리소스가 없다면 404 Not Found 응답을 보냅니다.
이러한 권한 체크는 주로 스프링 시큐리티 라이브러리를 사용해서 구현합니다.
스프링에서는 주로 SpringSecurity 라이브러리를 사용해서 권한 체크를 구현합니다. 여기서 몇 가지 중요한 클래스와 인터페이스를 살펴볼 수 있습니다.
먼저 AuthenticationManager라는 인터페이스가 있는데, 이것은 인증을 처리하는 역할을 합니다. 주로 ProviderManager라는 구현체를 사용합니다.
그 다음 AccessDecisionManager라는 인터페이스가 있습니다. 이것은 인가를 내리는 역할을 합니다. AffirmativeBased, ConsensusBased 같은 구현체들이 있습니다.
HTTP 요청에 대한 접근 제어 결정을 내리는 FilterSecurityInterceptor라는 필터도 있습니다. 이것은 SecurityFilterChain의 마지막에 위치해서 최종적인 권한 체크를 수행합니다.
메소드 레벨에서 권한을 체크할 때는 @PreAuthorize, @PostAuthorize 같은 어노테이션을 사용할 수 있습니다. 이를 통해 복잡한 권한 로직도 구현할 수 있습니다.
사용자 정보를 로드하는 UserDetailsService 인터페이스도 중요합니다. 이것을 통해 데이터베이스나 다른 저장소에서 사용자 정보를 가져와 인증에 사용하게 됩니다.
마지막으로 GrantedAuthority 인터페이스가 있는데, 이것은 사용자에게 부여된 권한을 나타냅니다. 주로 SimpleGrantedAuthority라는 구현체를 사용합니다.
이러한 클래스들이 서로 상호작용하면서 Put Mapping "/character/{id}" 같은 요청에 대한 인증과 인가를 수행하게 됩니다. 개발자는 이러한 클래스들을 구성하고 커스터마이징해서 애플리케이션의 보안 요구사항을 충족시킬 수 있습니다.
Last updated