회원가입 시 이메일 인증 하는 이유 본인인증이 포함되어야 무차별적 회원가입을 막을 수 있다. 로그인, 이메일 인증 과 같이 인증 진행 중 실패시에 응답을 애매하게 줘야 하는 이유 너무 친절한 인증 실패 메세지는 공격자에게 힌트를 주는 것과 같다. PasswordEncoder 사용자가 회원가입할 때 제공하는 비밀번호를 평문으로 DB에 저장하면 절대 안되고 무조건 암호화 해야한다. Spring Security가 제공하는 PasswordEncoder를 통해 어떤 알고리즘을 사용해 암호화할지 정할 수 있다. 평소에 같은 평문을 암호화한 해쉬값이 맨날 달라진건 알았지만 왜 그런건진 몰랐는데 이는 솔트 때문이다. // BcryptPasswordEncoder @Override public String encode(C..
@Basic @Target({METHOD, FIELD}) @Retention(RUNTIME) public @interface Basic { /** * (Optional) Defines whether the value of the field or property should * be lazily loaded or must be eagerly fetched. The EAGER * strategy is a requirement on the persistence provider runtime * that the value must be eagerly fetched. The LAZY * strategy is a hint to the persistence provider runtime. * If not specif..
View에서 접근 가능한 유저정보를 컨트롤러에서 Model로 넘겨주는 이유 블로그 포스팅 그동안 상단 헤더바에 들어가는 사용자에 대한 정보를 컨트롤러에서 @Authentication Principal로 받아서 모델에 추가해서 뷰로 넘겨 사용했다. 그러다 보니 모든 컨트롤러에서 세션 정보를 받아와 있는지 없는지 확인하고 있으면 닉네임, 감정을 모델에 추가해주는 코드를 넣어서 사용해왔다. 그러다 baeldung에서 해결법을 찾아 해결했다. 일단 이전 코드 먼저 보겠다. PostController, ControllerUtil public class PostController { private final PostService postService; @GetMapping("/posts") public String..
사용자가 자신의 닉네임, 비밀번호를 바꾸거나 댓글필터를 적용할 감정을 바꿔야 할 수 있어야 하기에 해당 부분을 구현해본다. 댓글감정필터란 ? 짧게 요약하면 긍정,중립,부정의 댓글 중 자신이 보고싶은 범위의 댓글만 볼 수 있게 해주는 서비스 https://anythingis.tistory.com/89 [Spring Boot JPA 커뮤니티] 댓글 필터링 서비스 https://anythingis.tistory.com/82 지난 댓글 작성 포스트 [Spring Boot JPA 커뮤니티] 댓글 작성, 네이버 감정분석 API 활용 기존 CRUD 게시판에 댓글 작성 시 감정 분석 API를 사용해 긍정, 중립, 부정으로 댓글 anythingis.tistory.com User Entity @Entity @Getter ..
https://anythingis.tistory.com/82 지난 댓글 작성 포스트 [Spring Boot JPA 커뮤니티] 댓글 작성, 네이버 감정분석 API 활용 기존 CRUD 게시판에 댓글 작성 시 감정 분석 API를 사용해 긍정, 중립, 부정으로 댓글 태그를 관리해 사용자가 원하는 댓글만 필터링하기 위해 댓글 작성 서비스에 네이버 API 적용 및 댓글 작성 및 anythingis.tistory.com 댓글 작성 시에 네이버 감정분석 API를 사용해 댓글마다의 감정을 갖고 있는데 사용자가 보고 싶은 감정까지만 보기 위한 기능을 추가할 예정이다. User Entity @Entity @Getter @NoArgsConstructor public class User extends TimeEntity { @..
예외처리는 예외가 발생할 수 있는 곳에 예외처리를 해 어플리케이션이 멈추지 않게끔 만드는 것이다. 스프링의 기본 예외처리는 예외 발생시 WAS에서 /error request가 발생해 BasicErrorController에서 받는다. 컨트롤러 내부에서 발생하면 WAS까지 갔다가 다시 에러 컨트롤러를 호출하는 것이다. 이런 낭비를 막고 예외처리를 커스텀 하기 위해 이번 글에선 두 부분을 다룬다. 1. Unchecked Exception 처리(예외 처리가 가능한 예외/ 컨트롤러 하위) Exception 중 컴파일 에러가 뜨는 Checked Exception을 제외한 Runtime Exception을 상속받는 모든 예외 처리. 사용자가 클릭만 이용한다면 터질일이 없지만 URI로 접근해서 해당 글, 해당 사용자,..
그동안 아무런 예외 처리를 하지 않고 컨트롤러에서 받아 서비스로 넘겨서 Entity에 지정한 옵션들과 일치하지 않으면 수많은 하얀 페이지를 만났다. 다른 템플릿 엔진은 예외처리를 할 클래스를 만들어서 View에서 처리해줘야하는 것 같은데 타임리프는 BindingResult를 모델로 넘겨 사용할 수 있고 시큐리티와 연동되는 부분도 많아서 꽤 간단한 편이였던것 같다. 이번 포스트는 회원가입, 로그인부터 살펴보고 다음 포스트는 서비스에서 터지는 예외처리로 넘어가겠다. 회원가입 User Entity @Entity @Getter @NoArgsConstructor public class User extends TimeEntity { @Id @GeneratedValue(strategy = GenerationType...
