고민의 흔적 (~ing)

# Entity를 정의할때 @Notnull, @NotBlank 같은 것들을 쓰는게 좋은가?

1. 대부분의 값들은 not null인데 이걸 굳이 attribute마다 붙여주자니 너무 비효율적이지 않나?
2. 차라리 값 검증코드를 따로 짜서 처리하는게 좋으려나?
3. 생각해보니 @Column(nullable = false)로 해도 되지 않나?
   @NotNull 어노테이션은 Hibernate Validator에서 제공되며 필드값의 유효성 검사를 수행
   nullable=false는 해당 필드에 대해 데이터베이스에서 NOT NULL 제약 조건을 생성하는 것
   둘 다 사용하는것은 중복코드라고 볼 수 있으므로 데이터베이스의 무결성을 보장하는 nullable=false만 사용하는 것이 좋음
   
   # 결론
   nullable = false를 사용하자. 하지만 필드값 검증하는 코드를 따로 작성하자.
   
   어짜피 검증코드를 짜야한다면 둘다 사용하는게 더 나은것 같기도하고... 딱히 정답은 없는 부분인건가라는 생각이 듭니다.
   
   

# 토큰, 쿠키, 세션 중 가장 이상적인 로그인 인증 방식 형태는 무엇인가?

모든 웹사이트가 각각 로그인 방식이 다르다. 최선의 방식은 존재하지 않는걸까? 

1. 쿠키만 사용, 세션만 사용
   석기시대 방식, 특히 보안 답없음 
   
   
2. 쿠키 + 세션
   나름 역사도 좀 있고 현재도 좋은 방식
   쿠키에 세션아이디를 관리하는 방식인데 보안문제를 해결할 수 있지만 세션을 유지하는데 서버에 부담이 갈 수 있습니다. 또한, 멀티 디바이스에서 인증정보 공유가 어렵습니다.
   
   
3. 쿠키 + 토큰
   chatgpt가 추천한 방식
   쿠키+세션보다 확장성, 유연성이 뛰어나다는점이 가장 좋은 점이고 서버 부하도 적음, 탈취만 안 당한다는 가정하에 최선이라 생각됩니다.
   
   

# 결론

환경에 따라 최적의 로그인방식이 다를 수 있지만 쿠키 + 토큰방식은 대체로 좋다.

 

 

 

# 조금 엉뚱한 고민

1. javax.validation의 보안성을 의심없이 믿고 써도 되는가?
   충분히 믿을만합니다. 다만 100%것은 존재하지 않기 때문에 중요한 데이터는 더 강력한 보안체계가 필요하고 적절한 예외처리와 로깅을 해주는것이 좋습니다.
   
   
2. entity에서는 대부분 값의 변경을 막기위해 @Setter를 사용하지 않는데 왜 DTO에서는 @Setter를 사용하는거지?
   DTO는 Controller와 Service 간에 데이터를 전송하기 위한 객체로 사용되는 경우가 많습니다. DTO 클래스는 데이터를 전송하기 위한 용도로 사용되기 때문에 setter 메서드를 제공하는 것이 일반적입니다.
   
   예를 들어, Controller에서 DTO 객체를 받아서 Service로 전달할 때 setter 메서드를 사용하여 DTO 객체의 값을 변경하고, Service에서는 DTO 객체를 이용하여 데이터를 처리한 후 결과를 DTO 객체에 담아서 Controller로 전달할 수 있습니다.
   
   
3. @NoArgsConstructor는 굳이 왜 필요할까? 어짜피 내부 변수값을 설정해줘야하는거 아닌가?