개인 보안 노트 프로젝트 작성 과정 , 느낀점

해당 프로젝트는 클론 코딩의 일부로써, 개인이 진행하였다. 

 

spring security의 사용 뿐만 아니라, 앞서 진행했던 spring의 기본기와 spring boot등을 최대한 활용하고자 하였다. 

 

Package는

Admin, notes,notice,user,config 이렇게 기능이 아닌 각 도메인별로 분할하였다. 

 

과정 진행중 특히  Spring Security 6와의 차이 때문에 애를 많이 먹었다. 

현재 Spring Security가 6이 되며, 기존 코드들이 많이 decrepted 되어 설정이 특히나 어려웠다. 

해당 configuriation을, https://jihyukcoding.tistory.com/94에 작성해 두었다. 

 

이제 각 도메인 별로 설명을 진행하고자 한다. 

 

1. User

 

database에는 user table이 생성된다. 해당 user table은, spring security의 userdetails를 상속받은 형태이다. 

굳이 이를 사용해줘야 하는 이유는, Spring Security의 다양한 role 관리 등을 위해 해당 인터페이스를 사용하기로 약속되었기 때문이다. 

 

또한, TABLE NAME을 별도 설정해 주지않으면 User 기본 TABLE과 충돌하기 때문에 user로 설정해주었다

(DBMS는, 대소문자에 민감한 경우가 많다 ) 

 

 

Exception의 경우는, 더 많고 상세하게 가능하나  USERNOTFOUND와 ALREADYREGISTERDEXCEPTION을 생성했다. 기본 RUNTIMEEXCEPTION을 그대로 사용하거나, 혹은 특정 경우에는 MESSAGE를 추가하기 위함이다. 

 

REPOSITORY는, JPAREPOSITORY를 그대로 사용하였다. JPAREPOSITORY는 METHOD의 선언 만으로 구현이 가능한데, SERVICE단에서 즉시 사용하기 위해 이를 구현하였다 . (안해도 상관없다)

 

Service 단, 회원가입을 관리했다.  jparepository의 save기능을 활용하였고, user의 authority에 "ROLE_USER"를 대입했다. 

 

PASSWORDENCODER를 사용하였음에 유의하자! 

 

 

Controller 단은, 크게 일반적인 모델과 다를것이 없다. 

@Modelattribute정도 헷갈릴 수 있는데, 이는 thymeleaf 구문을 활용하였기 때문에 해당 model을 통해 이를 thymeleaf로 작성된 프론트 단에 변수를 넘기기 위함이다. 

 

2.Note 

 

기본적인 구조는 큰 문제가 없으나, 문제가 있었던 부분을 위주로 작성하겠다. 

 

앞서 블로그에 작성했던, 관계에 대한 문제. 해당 CLASS는 NOTE에서 발췌했다.

NOTE와 USER는, MANY TO ONE의 관계를 지닌다. (한 USER가, 여러가지의 NOTE를 쓴다)

USER user로 작성하였음에도 불구하고, User와 Note는 user의 id로 join을 진행한다. 해당 의미를 joincolumn으로 표현했다.

 

jpa 레퍼지토리를 통해 자동 메소드 생성시 주의점. 

대문자, 정해진 순서, and , order와 같은 문법을 모 두 일치시켜야한다.

 

 transactional의 문제. 삭제와 검색과 같은 경우에, 트랜잭션 단위로 실행되게 주의하였다. 

 

잠깐 notice의 예시를 가져왔다. 

나는 항상 post,delete 등에서 requestbody의 값을 dto로 가져와 그것을 사용할 생각만 했었는데, 그러지 말고 

매우 간단하게 @PathVariable 혹은 @RequestParam으로 쓸 수 있다.

물론. url의 차이는 존재한다. 

 

REquest Param

http://예제.com/예제?매개변수=넣을값

Pathvariable 

http://예제.com/예제/넣을값

 

 

userdetails를 다시 받았기 때문에, spring security에서 관리되는 GrantedAuthority에, 본인의 authority를 넣는다. 

 

autority의 설정은 이렇게 해주는데, ROLE_로 시작하는 것이 관례이다. 

 

POSTCONSTRUCT를 사용하여, 기본적인 사용자와 어드민이 존재하게 하였다. (SIGNUP시 자동으로 사용자로 가입된다)

 

https://jihyukcoding.tistory.com/94

Spring Security Config

앞서 말한대로, 이후 전 CONFIG 내용을 정리해 두었다. 

 

? 로그인은 구현 안했는데? 

 

해당 내용이 핵심이다. 로그인 페이지가 ("/login")임을 mapping해주고, 성공했을때와 해당 로그인 페이지의 구현 정도만을 제시하면 된다. 

 

사용자 로그인 페이지 

form - control을 통해 post 요청을 보내면, spring security에서

username과, password에 맞는 내용을 가져온다. (변수의 이름을 바꾸지 않게 주의하자)

 

 

-- 느낀점 --

 

JWT로의 전환도 도전하였으나, SPRING SEUCIRTY 6로 넘어가며 생긴 변화들 때문에 이루지 못하였다. 

해당 내용이 아쉽다. 

 

SPRING SECURITY는 넓은 확장성과 로그인 구현을 안해도 되는 등 편리한 점을 지니나, 이에 따라 주의해야할 변수명 등이 늘어났다.

 

spring security를 활용한 로그인 과정에 대해 경험할 수 있었다.