안녕 퇴물이 왔다.

주말동안 써보고 좋았던게 있어서 이야기 해보고자 한다.


요즘 JSON 상하차를 주로 하다보니. 코드가 좀 더러운데...

주요원인은 실제 로직보다는 로직 앞 뒤로 삼겹살 지방처럼 덕지덕지 붙어있는 보안 요소 때문임.


1) DTO로 제대로된 포맷으로 왔는지 BadRequest 인지 검증하고.

2) DTO로 허용은 되지만, 사용자 권한이나 레벨에 따라서 또 Forbidden 처리를 해야함.

3) 실제 코어는 단순하게 연산 한번하고 DB에 Insert 하는 정도일 것임.


간단하고 자주보는 흔한 예로, 게시판의 경우 본인과 관리자만 삭제하고 수정할 수 있다던지.
DC처럼 파딱이나 주딱은 일반유저인데도 권한이 있어서 삭제할 수 있다던지.

사실상 상당수의 CRUD에는 이런걸 해야 되는 경우가 보통임.


아예 관리자용과 유저용의 rest api 경로를 분리해서 사용하는 경우가 많으나

관리요소가 이원화되서 난 별로 이런 형태는 피할려고 하는 편임.


그럴때 좀 쓰기 쉬우라고 나온게 보통 Access Control 라이브러리라고 부름.

내가 쓴건 CASL.js 이라는 놈임.


니네들도 대부분 눈치챘겠지만 나는 머리가 좋지 않아서 어려운 코딩을 못함.


나는 React도 어려워서 못함.

막 HTML 템플릿 코드에 .map 같은 JS 코드가 막 섞여있으면 넘 복잡해서 지능이 따라가질 못함.

십수년전만해도 PHP나 ASP를 로직과 뷰가 마구 섞인 스파게티식 코드라고 존나게 안좋게 봤으면서

최신 React도 똑같은 짓 하는데도 빠는거 보면 이해가 잘 안됨.


그래서 서비스 로직부분에는 살균처리된 깨끗한 상태의 데이터만 왔으면 좋겠고.

그 앞단에서 필터링으로 살균해서 자격이 없으면 호출을 걸러낼 부분은 별도로 있었으면 했음.


보통은 이걸 미들웨어라고 부르면서 앞단에 한번 걸러져서 들어가는 함수로 많이 씀.

근데 이게 또 상황별로 미들웨어가 너무 많아지면서 유지보수가 귀찮아짐. (근데 원래 이렇게 하는게 대충 맞긴 함)


CASL을 보니까 나같은 저지능도 쓸 수 있게끔 간단함.



7fed8272a8826eeb3fe796e54391756a10d0ab810cb88e87cd077db680b229647b86


FeathersJS에서 사용하는 hook이라는 건데. 리엑트의 훅이랑은 다르고.
후킹함수라고 그냥 함수 앞뒤로 붙이는 미들웨어 덩어리라고 보면 됨.


before create 쪽보면, create(post) 들어오면, 본 라우팅된 서비스의 함수로 연결하기 전에
DTO 검증하고, fill 어쩌고는 디폴트 값이나 트랜스폼할 값 채우고나서. 서비스(컨트롤러) 함수로 연결함.


CASL은 can, cannot으로 필드의 값에 대해서도 한번 더 필터링 해주는데,

isByung.. 이것처럼 사용자한테 보여주면 안되는 것들은 select 문에서 제외한 것처럼 레코드 셋에서 빼버림.


아무튼 코드가 쉽다!!

영어도 딱 내수준에 맞는 can, cannot 두개 뿐이여!


보안상 채크 해야될 룰만 따로 서비스 클래스와 분리 되어있다!

이게 분리되면 로직이 들어간 서비스 함수는 로직 살코기만 남아서 더 담백해짐.


일단 사용자의 권한과 그룹을 기준으로 다르게 설정 가능하고,

코드 베이스로 룰을 정할 수 있고 can,cannot으로 설정하면 최종적으로 rules라는 json 데이터로 저장되니.

스테틱 하드코드 방식외에도 DB에 넣고 런타임에서 권한을 바꿔줄 수 있음.


RBAC, ABAC 같은거 간단히 배워서 써보셈.
코딩 좀 치는 친구들은 Casbin 같은거 배우면 여러 언어에서 쓸 수 있고 좋은듯... 근데 이건 내가 지능이 못 따라가서 못씀.


AccessControl 되게 많이 쓰이는데 코딩할때 얘기 나오는건 별로 못 봄.

걍 대충 유저 레벨로 쳐바르던데..


음...


다시 생각해보니 그냥 편하게 유저레벨이나 쓸 껄 왜 또 오버엔지니어링하고 있나 싶어서 허무감 살짝듬.