![]()
# 등장배경 서드파티 어플리케이션이 사용자 대신 페북에 영향을 주거나 정보를 가져오려고 한다고 가정해 봅시다. 가장 기본적인 방법은 서드파티가 id, pw를 사용자로부터 입력 받아서 서드파티가 다른 서비스에 대신 로그인해서 접근하는 방식입니다. 하지만 이 방법에 치명적인 단점이 있는데 페북 id, pw를 서드파티가 관리할만큼 믿을만 한가에 대한 의문입니다. 즉, 서드파티의 보안수준이 페북의 보안수준이 되어버리는 문제가 발생합니다. 이를 해결하기 위해 서비스별로 여러가지 auth방식이 나왔는데 이를 OAuth로 통일시키기로했습니다. # OAuth란 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization)..
![]()
무지성 박치기로 로그인을 구현하려했다가 몇주를 헤맸던지... 만약 처음으로 로그인을 구현하려 한다면 documentation부터 차근차근 보는것을 추천합니다. 깃헙 뒤지고 아무리 구글링해도 내가 딱 원하는 나만의 로그인을 구현하다보면 생각외로 굉장히 많은 생소한 에러를 발견합니다. 1. SecurityContextHolder SecurityContextHolder는 SecurityContext를 가지고 있고 이를 통해 인증을 증명할 수 있습니다. 일반적으로 thread-local을 사용해서 정보를 저장하기 때문에 동일한 스레드라면 항상 SecurityContext에 접근 가능합니다. 다른 방식을 원하면 따로 설정 가능합니다. 2. SecurityContext Authentication 객체를 가지고 있습..
![]()
# Spring Security란? Spring Security는 Java 기반의 응용 프로그램에서 보안을 구현하기 위한 강력하고 널리 사용되는 프레임워크입니다. 인증, 권한 부여, 세션 관리 및 일반적인 보안 위협으로부터의 보호 등 다양한 보안 관련 문제를 해결하기 위한 기능을 제공합니다. 결론은 개발자가 좀 더 간편하게 보안을 구현할 수 있도록 도와주는 프레임워크입니다. # 구조 아주 간단하게 말해서 등록된 수많은 filter들을 통과한 요청을 안전한 요청으로 처리하는 식입니다. DelegatingFilterProxy 보통 서블릿 필터는 web.xml 파일에 직접 등록되어 사용됩니다. 반면, spring에서는 web.xml보다 JavaConfig 설정 파일을 사용합니다. delegatingFilter..
# Entity를 정의할때 @Notnull, @NotBlank 같은 것들을 쓰는게 좋은가? 대부분의 값들은 not null인데 이걸 굳이 attribute마다 붙여주자니 너무 비효율적이지 않나? 차라리 값 검증코드를 따로 짜서 처리하는게 좋으려나? 생각해보니 @Column(nullable = false)로 해도 되지 않나? @NotNull 어노테이션은 Hibernate Validator에서 제공되며 필드값의 유효성 검사를 수행 nullable=false는 해당 필드에 대해 데이터베이스에서 NOT NULL 제약 조건을 생성하는 것 둘 다 사용하는것은 중복코드라고 볼 수 있으므로 데이터베이스의 무결성을 보장하는 nullable=false만 사용하는 것이 좋음 # 결론 nullable = false를 사용하자..
id PK, AI username UNIQUE, NOT NULL, length(30) userid UNIQUE, NOT NULL, length(30) password NOT NULL, length(30) email UNIQUE, NOT NULL, length(100) grade NOT NULL, default = CLIENT 회원 [ id, username, userid, userpassword, email, grade] 종류로는 일반회원, 관리자가 존재 enum Grade{ CLIENT, ADMIN } 회원가입 (username, userid, password, email [인증 필요]) 이메일 인증 구현 이메일 인증 테이블 관리 로그인 (userid, password) jwt 토큰 기반 인증 소셜 로..
