전체 글

Cookie / Session / Token 인증 방식 종류 일반적으로 서버가 클라이언트 인증을 확인하는 방식은 크게 쿠키, 세션, 토큰 3가지 방식이 있다. Cookie 인증 쿠키는 Key-Value 형식의 문자열이다. 클라이언트가 어떤 웹사이트에 방문하면, 그 사이트의 서버를 통해 브라우저에 설치되는 정보 기록용 파일이다. 그래서 각 사용자마다 고유 정보 식별이 가능해진다. Cookie 인증 방식 브라우저가 서버에 요청을 보낸다. 서버는 요청에 대한 응답에 브라우저에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다. 이후 브라우저는 요청을 보낼 때마다 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다. 서버는 쿠키에 담긴 정보를 바탕으로 요청의 주체를 식별한다. Cookie 방식의 ..

Refresh token이 필요한 이유 Access token 만을 통한 인증 방식의 문제는, 제 3자에게 탈취당할 경우 보안에 취약하다는 점이다. 발급된 이후에는 서버에 저장되지 않아 토큰 자체로 검증을 하며 사용자 권한을 인증하기 때문에 Access token이 탈취되면 토큰이 만료되기 전까지 토큰을 가지고 있는 사람은 누구나 접근 권한을 가진다. JWT는 발급 후 삭제가 불가능해서 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대응을 하고 있다. 보통은 유효기간을 짧게 하여 탈취당했을 때의 악용 시간 자체를 줄이는 해결책이 있긴 하지만, 그만큼 사용자는 자주 로그인을 하여 토큰을 발급받아야 하는 불편함이 있었다. 이러한 이유로 Refresh token이 나오게 되었다. 이름이 Refresh toke..

@PostMapping public ResponseEntity createPost( PostCreateRequest requestDto, HttpServletRequest servletRequest) { LoginUser loginUser = statusUtil.getLoginUser(servletRequest); postService.createPost(loginUser, requestDto); return ResponseEntity.ok().build(); } 응답에 바디가 없는 API를 테스트할 때 위와 같은 컨트롤러가 있고, @Transactional public void createPost(LoginUser loginUser, PostCreateRequest requestDto) { User u..

어제에 이어서, 할일카드 단건 조회 시 좋아요 수를 함께 조회하는 기능을 구현했었다. @Getter @Entity @Table(name = "todocard") // 테이블명 명시 @NoArgsConstructor(access = AccessLevel.PROTECTED) // JPA 엔티티의 최소 접근제어자로 설정 public class TodoCard extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(length = 500, nullable = false) private String title; @Column(length = 5000, nullable = false) pr..

스프링 데이터 JPA의 Query method 에서 엔티티의 연관 엔티티의 필드를 가져오는 한 방식을 알게 되었다. @Getter @Entity @Table(name = "likes") @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Like { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "user_id") private User user; @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "todocard_id..

레포지토리에서 특정 id로 엔티티를 가져올 때, Optional로 반환을 하기 때문에 서비스단에서 예외처리를 그동안 해주었다. 근데 과제 중에 튜터님이 쓰윽 지나가시다가 레포지토리 단에서 예외를 발생토록 하는 방식도 있다고 알려주고 가셨다. 기존에 쓰던 서비스단에서 예외처리는 다음과 같다. @Service @Transactional(readOnly = true) @RequiredArgsConstructor public class TodoCardService { private final TodoCardRepository todoCardRepository; /** * 할일카드 단건 조회 */ public TodoCardDetailResponseDto getTodoCard(Long todoCardId) { T..

Cascade (영속성 전이) 사용 위치 연관관계의 주인 반대편 - 부모 엔티티(다대일에서 일) 즉, @OneToMany 가 있는 쪽 (@OneToOne 도 가능) 예를들어, 게시글과 첨부파일이라면 일에 해당하는 게시글에 설정한다. 사용 조건 양쪽 엔티티의 라이프사이클이 동일하거나 비슷해야한다. (게시글이 삭제되면 첨부파일도 같이 삭제 되어야 하는 경우) 대상 엔티티로의 영속성 전이는 현재 엔티티에서만 전이 되어야 하며, 다른 곳에서 또 걸면 안 된다. (첨부파일을 게시글이 아닌 다른곳에서 영속성 전이를 하면 안됨) 옵션 종류 ALL : 전체 상태 전이 PERSIST : 저장 상태 전이 REMOVE : 삭제 상태 전이 MERGE : 업데이트 상태 전이 REFERESH : 갱신 상태 전이 DETACH : ..

QueryDSL 세팅법 스프링 부트 3버전 이상을 기준으로 한다. dependencies { // ... implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta' annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta" annotationProcessor "jakarta.annotation:jakarta.annotation-api" annotationProcessor "jakarta.persistence:jakarta.persistence-api" } QueryDSL 세팅 객체를 만들어준다. @Configu..

참조 지역성이란 기억장치로부터 참조될 때 시간적, 공간적, 순차적으로 분포가 집중되는 성질을 말한다. 크게 시간 지역성과 공간 지역성으로 나눌 수 있다. (순차 지역성은 보통 공간 지역성에 편입하여 설명된다.) x축은 시간, y축은 연속된 메모리 주소이다. 시간 지역성은 최근에 참조된 주소는 다시 참조될 확률이 높은 성질이다. 시간 지역성의 예시로, CPU 스케쥴링을 들 수 있다. CPU에서 처리할 프로세스를 설정할 때, 최근에 사용된 프로세스는 다시 사용될 가능성이 높다고 판단하여 우선순위를 높여서 처리되게끔 한다. CPU 스케쥴링 방식에는 크게 선점과 비선점 방식이 있다. 비선정 방식은 프로세스가 들어오는 순차적으로 처리하는 방식이다. 구현은 단순하지만, 프로세스의 중요도와 걸리는 시간을 고려하지 않..