이 사용자가 이 기능을 사용할 수 있다면 어떻게 그런 것을 실현할 수 있겠는가

이 사용자가 이 기능을 사용할 수 있다면 어떻게 그런 것을 실현할 수 있겠는가

결론

DB로 구현하거나 응용 프로그램 측면에서 프로그램 라이브러리를 통해 구현합니다.카스빈이 강해 보여요.
https://casbin.org/en/

개시하다

사용자 테이블에서 isAdmin열을 사용하면 아드레날린인지 여부에 따라 접근 제어를 구분하지만 서비스가 커지기 때문에 더욱 상세한 제어가 필요하다.그래서 나는 정보를 수집하는 견해를 총결하였다.

액세스 제어 인식

누가 이 서류 같은 걸 조작할 수 있겠어?물어볼 수 있는 4가지 패턴이 있는 것 같아요.

DAC

RBAC

MAC

ABAC

DAC, RBAC 및 MAC

나는 이 세 가지를 함께 그림으로 이해하면 더욱 기억하기 쉽다고 생각한다.

DAC(임의 액세스 제어)는 사용자 측 임의의 사용자가 이 기능을 사용하도록 설정합니다.예를 들어 구글에서 파일을 공유할 때 누구나 열람할 수 있는 내용을 설정한다.그나저나 리눅스에 사용되는 파일 시스템 등.반면 MAC(강제 액세스 제어)는 시스템에서 각 단계까지 사용할 수 있는 기능을 완전히 제한한다.군대에 자주 이용되다.예를 들어 매우 하등이라면 이 정도의 정보만 얻을 수 있다.DAC의 단점은 사용자에게 너무 많은 자유를 주는 것이다.MAC는 순수 수준이 높아지면 이용할 수 있는 기능이 증가하는 모델이기 때문에 제작은 가능하지만 이런 표현 단점을 열람할 수 없다.
RBAC(볼륨 기반 액세스 제어)는 두 가지에 비해 상대적으로 새롭습니다.롤러라는 중간층을 설치하다.사용자는 할당할 수 있는 역할의 기능만 사용할 수 있습니다.시스템 측면에서 볼 때 사용자에게 자유를 주지 않을 뿐만 아니라 기능 분배도 비교적 높다.

ABAC

좀 까다롭다.최종 진화계일 수도 있어.이것은 조건을 복잡하게 하는 물건이다.예컨대

본점에서 근무하며 점장급이면 삭제(열람, 제작, 업데이트 가능)

점장급이면 열람, 제작, 업데이트 가능

지점에서 일하면 열람할 수 있다
이처럼 그 사람의 속성에 따라 권한의 생각을 미세하게 바꾼다.매우 복잡하다.좀 더 간단하면 RBAC도 대응할 수 있다고 생각합니다.

본점의 점장 역할은 모든 권한이 있다

지점장 역할은 열람, 제작, 업데이트가 가능하다.

지점 아르바이트생 역할은 열람만 가능하다.
이런 느낌.

적용 권한 관리에 DAC, RBAC 및 MAC를 적용해 보십시오.

위에서 언급한 것은 시스템 수준의 접근 내용의 선별인데 웹 서비스 권한 부분과는 조금 다르다(사용자가 권한을 자유롭게 관리할 수 있다면 권한의 의미가 없다).다만 상술한 그림은 권한 관리에 사용할 수 있을 것 같다.여기에 상술한 그림을 힌트로 삼아 다른 생각을 해 보자.
다음은 DB를 이용하여 동적 변화가 없으면 텍스트 파일(yml 같은)도 가능하다.

사용자 id로 직접 연결하는 모드

DB를 사용하여 다음 사용 권한 테이블을 만듭니다.
userId
view
create
edit
delete
1
true
true
true
true
2
true
false
false
false
응용 분야에서 권한표join을 사용자가 얻는 데 사용하고 각 작업의 진위를 미리 유지합니다.

const create = () => {
  // さすがにuser.createという取得は嫌なので
  if(!user.create){
    throw new Error('create is not permitted.');
  }
  
  // create something.
} 

캐릭터와 연관 가능한 패턴

DB에서user표에서role열을 진행할 수 있으며, 권한표에서roleId와 동작을 연결할 수 있습니다.
사용자 테이블
userId
name
roleId
1
bob
1
2
alice
2
사용 권한 테이블
roleId
name
view
create
edit
delete
1
ADMIN
true
true
true
true
2
GUEST
true
false
false
false
응용 프로그램 사이드 코드

const create = () => {
  if(!user.role.create){
    throw new Error('create is not permitted.');
  }
  
  // create something.
} 

또는 선택도 있습니다.user표에role열만 놓고 권한표를 만들지 않습니다.이런 상황에서 응용 프로그램 방면에서 지점을 진행한다.

const create = () => {
  // 対応ロールが増えるとここの分岐が増える。
  // const permissions = ['ADMIN', 'LEADER']として、if(permissions.includes(user.role)) とするのもあり。
  if(user.role !== 'ADMIN){
    throw new Error(`role need admin. you role: ${user.role}`);
  }
  
  // create something.
} 

또는 RBAC를 실현할 수 있는 프로그램 라이브러리를 가져와 프로그램 측면의 어느 곳에서 권한표를 미리 설명하는 부분도 가져온다.

사용자에게 등급을 부여하는 모드

사용자 테이블에 등급 표시줄을 추가하고 프로그램 측면에서 등급이 한도값 이상인지 확인합니다.어느 등급의 권한이 어떤 조작을 할 수 있는지에 대한 정보를 문서에 잘 정리하지 않으면 지옥에 갈 수 있다.
사용자 테이블
userId
name
level
1
bob
2
2
alice
1
응용 프로그램 사이드 코드

const create = () => {
  if(!user.level <= 1){
    throw new Error('create is not permitted.');
  }
  
  // create something.
} 

specification 모드

디자인 모델 중 하나는specification 모델입니다.DDD책 어딘가에 나타나서복잡한 조건을 처리하는 비즈니스 논리의 모델.이걸 이용하는 방법도 있을 것 같은데.

끝말

이 분야의 초보자이기 때문에 자세히 알려주시면 감사하겠습니다^^