그룹이 있다. 그룹에는 개인이 속한다. 그룹에는 그룹이 속할 수 있다.
개인이 있다. 개인은 그룹에 속할 수 있고, 여러 그룹에 속할 수 있다.
메뉴가 있다. 이 메뉴에 접근할 수 있는 대상을 지정할 수 있는데 그것은 그룹이 될 수도 있고 개인이 될 수도 있다.
메뉴에 A 그룹은 조회가 가능하다 설정하면
A그룹에 속한 개인 모두와, A그룹 밑에 있는 B그룹에 속한 모두가 조회 가능하다.
메뉴에 B그룹은 조회가 가능하다 설정하면
B그룹에 속한 개인 모두가 조회 가능하다. 하지만 B그룹의 윗그룹인 A그룹에서는 조회가 불가능하다.
=============================================
권한 설계 위에 쓴것처럼 한번 해봤어. 논리적 오류가 없겠지?
그리고 헷갈리는 부분이 있는데 아래부분임..
그룹 권한도 하위 전파가 되게 했으니, 메뉴 계층도 그래야하는가?
Q. 메뉴도 계층이 있다고 가정했을 때 상위 메뉴에 특정 그룹을 할당하면, 해당 그룹은 하위메뉴까지 권한을 가져야하는가?
개인이 있다. 개인은 그룹에 속할 수 있고, 여러 그룹에 속할 수 있다.
메뉴가 있다. 이 메뉴에 접근할 수 있는 대상을 지정할 수 있는데 그것은 그룹이 될 수도 있고 개인이 될 수도 있다.
메뉴에 A 그룹은 조회가 가능하다 설정하면
A그룹에 속한 개인 모두와, A그룹 밑에 있는 B그룹에 속한 모두가 조회 가능하다.
메뉴에 B그룹은 조회가 가능하다 설정하면
B그룹에 속한 개인 모두가 조회 가능하다. 하지만 B그룹의 윗그룹인 A그룹에서는 조회가 불가능하다.
=============================================
권한 설계 위에 쓴것처럼 한번 해봤어. 논리적 오류가 없겠지?
그리고 헷갈리는 부분이 있는데 아래부분임..
그룹 권한도 하위 전파가 되게 했으니, 메뉴 계층도 그래야하는가?
Q. 메뉴도 계층이 있다고 가정했을 때 상위 메뉴에 특정 그룹을 할당하면, 해당 그룹은 하위메뉴까지 권한을 가져야하는가?
메뉴 계층도 권한을 오버라이딩 하게 하면 될듯 a메뉴 밑에 b메뉴 있으면 b는 디폴트로 a권한 따라가게 하고 b에 따로 설정된 권한이 있으면 그걸 적용하고
정책을 어떻게 설계하냐에 따라 다를거같긴한데, 하위전파되는 방식이면 그렇게 하는게 맞을듯
'그룹이 될 수있고 개인이 될수있다' 이부분이 꼭 필요한가? 너무 복잡해질거같은데
나도 그 부분 때문에 머리가 아픔. 근데 예를 들어 특정 그룹에 '게시판 조회,수정'권한을 부여했는데 그 그룹에 속한 개인에게만 '게시판 삭제'권한을 주려고 하는 상황을 가정하면 필요할거같음
이거 그냥 aws iam따라 하면 되잖음. 롤이랑 유저랑 그룹 이렇게 나누면 깔끔할듯
그러면 그룹 <-> 개인간의 권한 우선순위도 필요한건데 화면상으로도(실제 프로그램상에서) 개인, 그룹 권한부여 및 우선순위가 잘 표현될라나? 기능구현전에 화면적 기획을 한번 더 확인해봐. 사용성이 떨어지면 맨땅에 이유없이 일하게 됨.
문제는 화면적 기획이 없다는 것이다. 일단 기능 구현하고 화면은 그려준대..
잘 설명해봐. reference 도 잘 대보고. 개인, 그룹이 나눠야한다고 한걸 보니 요구사항은 있는거 같은데 요구사항 => 화면 및 설계서 갈 때 의견을 제대로 잘 피력해야함.(논리적으로) 요구사항이 뭔지, 서비스에 있어서 더 좋은게 뭔지, 개발력을 절약할 수 있는건 뭔지, 추 후 유지보수 및 프로그램을 발전시킬 때 어느게 좋을지 잘 저울질 해서 의견을 피력하도록 해. 정답이 뭐일지는 모르지만 다른사람도 설득할 수 있어야지. 설득안해도 되는 개발자는 커널개발자정도밖에 없지 않을까?
이거 딱 깃랩이랑 똑같은 권한체계임