들어가기 Http 방식이 가지는 가장 큰 특징 중 하나는 Stateless(무상태) 이다. 즉 서버는 사용자의 로그인상태를 유지하지 않는다. 이 무상태성을 해결하기위해 여러 방법이 존재하고 이 방법들을 알아보자. 매번 로그인 시키자 맞다. 말도 안되는 방식이고 어떤 서비스도 사용자를 매번 로그인 시키며 피로하게 만들지 않는다. 그렇다면 로그인 정보를 매번 전송하자 로그인 정보를 매번 전송해서 서버에게 나의 로그인 상태를 매번 알리는 방법이다. 그렇다면 어떻게 알리는 방법이 좋을까? HTTP Body, Query Parameter 혹은 Cookie에 로그인 정보(id,pw)를 담아 전송할 수 있다. 하지만 로그인 정보는 매우 민감한 정보이기 때문에 탈취당한다면 민감한 정보가 유출된다. 위 방식은 어떻게 해..
Spring
들어가기 저번 로그인 방식 글에 이어서 JWT를 알아보자. JWT 기반 로그인은 안전한가? 우선 토큰 기반의 로그인 방식은 서버가 생성은 하지만 관리는 클라이언트 측에서 하게된다. 클라이언트측은 토큰의 탈취 가능성을 염두해 예민한 정보는 토큰에 담지 않는다. JWT를 구성하는 Header, Payload, Signiture 3가지 파트 중 Header와 Payload는 base 64로 인코딩 되지만 공격자가 디코딩이 가능하기때문에 유저의 식별정보만 담아야한다. 서버는 사용자 요청이 오면 AccessToken을 생성해 반환한다. 이후 인가처리는 AccessToken 유효성 검사를 통해 위변조를 감지할 수 있다. AccessToken 탈취 AccessToken(이하 AT)을 탈취당할 경우를 대비해 토큰 만료..
우선 게시판 프로젝트의 아키텍처를 살펴보면 아래와 같다. Nginx에서 라운드 로빈 방식으로 부하를 분산하려는 시도를 했다. 원래는 여러 EC2에 스프링 톰캣 서버를 띄워야 EC2하나가 죽더라도 로드밸런싱의 의미가 있지만 작은 프로젝트였기 때문에 하나의 EC2에 Docker compose로 스프링 톰캣 서버를 2개 구축했다. 현재 로그인 방식은 세션 방식이기 때문에 Spring자체 세션 저장소를 이용했다. 사실! Spring서버에는 자체 세션 저장소는 없다. 범위를 벗어나는 이야기이기때문에 길게 설명하진 않겠지만 톰캣의 SESSION.ser 파일에 저장된다. 하지만 지금 WAS가 2개인 상황에선 세션을 고정 시킬 수 없었다. 해결방법을 고민해보던 중 몇 가지 대안을 찾았다. Nginx 로드밸런싱 알고리..
https://github.com/SQUAD-D/board GitHub - SQUAD-D/board Contribute to SQUAD-D/board development by creating an account on GitHub. github.com 게시판 프로젝트를 진행하면서 가장 깊은 고민이 였던 부분은 사용자의 고아 이미지 처리였다. 우선 고아 이미지가 어떻게 생성되는지 살펴보자. 사용자의 이미지는 게시글 작성 요청 시점이 아닌 업로드 즉시 AWS S3에 저장된다. @PostMapping(value = "/boards/img") public ImageInfoResponse saveImg( @RequestPart(value = "image") MultipartFile image) { return b..
게시판 프로젝트를 진행하면서 코드의 중복과 Null 처리를 어떻게 해야할 지 고민했다. 게시판의 전체 게시글과 특정 회원이 작성한 게시글을 뿌려주는 Service layer의 로직이 거의 유사했다. 단지 SQL문에 memberId를 where 조건문에 포함시키는 여부만 달랐다. 코드의 중복을 피하기위해서 기존의 전체 게시글을 뿌려주는 메서드에 memberId만 추가해서 구현하기로 결정했었다. Service 레이어의 메서드는 재사용이 가능해졌지만 한 가지 문제점이 있었다. 바로 null처리였다. 위 메서드를 사용하는 컨트롤러 메서드는 2개다. 문제는 첫 번째 컨트롤러다. memberId에 null을 건내주고있다는 점인데 저 부분이 상당히 마음에 걸렸다. memberId에 Null을 주면 전체 게시글을 조회..
Auto Flush 조건 지금까지 알고있었던 자동 flush 조건은 셋 중 하나였다. em.flush() 호출 트랜잭션 Commit 시점 JPQL 호출 직전 정말 JPQL 호출 직전 flush 할까? 눈으로 확인해보자. JQPL 호출 직전 flush 한다면 쿼리의 순서는 INSERT -> SELECT -> SELECT 순이여야한다. 실제 쿼리를 확인해보자. 예상이 아주 기분좋게 빗나갔다. 실제 순서는 SELECT -> INSERT -> SELECT 순이다. 이 이유는 Hibernate 공식 가이드에서 찾아볼 수 있다. Hibernate ORM 6.2.6.Final User Guide Fetching, essentially, is the process of grabbing data from the data..
문제상황 : 댓글에 좋아요가 눌린 뒤 댓글이 삭제되면 좋아요도 DB에서 삭제돼야했지만 삭제가 되지않았다. 외래키를 참조하고있기 때문에 삭제를 할 수 없다는 에러다. 먼저 Entity는 아래와 같다. @Entity @Getter @ToString @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Comment extends BaseTimeEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long commentId; // 댓글 식별자 @Column(nullable = false) private String content; // 댓글 내용 @ManyToOne(fetc..
