Guest, User Previleges를 express-acl로 관리하기.

ACL이 담당하는 것은 미들웨어의 접근권한

1. 미들웨어 접근 권한을 제어

Application < Router

2. 어플리케이션 내부 로직의 접근 및 관리 권한 제어

Board < Category < Document < { Functions }< Group < User < Access User

refer for acl, for XpressEngine.

Xe의 경우 global, session에 document번호를 기억해뒀다가 수정 및 관리 권한을 주게 만들었었다.

acl에서 role 한개를 정의 할 때는 보통

role = {

group : 'admin',

permissions : [

{

resource : 'users',

method : ['GET', 'POST', 'DELETE', 'PUT'],

action : 'allow' 

}

]

}

이런식으로 요청에 대응한 라우팅 접근 권한을 관리하는 구조.

여기서 이점을 본따고, 페이스북 api에서 퍼미션에 대해서 행위 기준점을 최대한 본따보자.

아래와 같이 특정 리소스 군 자체에 권한을 쥐어줄땐 아래와 같이 준다.

permission = {

resource : 'publish_board_document',

action : 'allow'

}

비회원이 문서 1개의 권한을 승인 받았다면, 퍼미션을 설정한다고 하자.

permission = {

resource : 'manage_board_document',

resource_id : board_id1.document_id1,

action : 'allow'

}

그 기능의 특정 기능을 의미하는거라면,

user.roles 는 역할적 권한을 의미한다.

- 이 역할을 담당하는 그룹에 소속 해줘

user.permissions 는 그룹 권한을 넘어선 배정 권한이라고 볼 수 있겠다.

- 특정 게시판 관리권한에 잠깐 소속해줘.

req.permissions 는 접근한 사람의 인스턴트한 권한을 보관하는 역할이다. 세션이 죽으면 날아가는 휘발성을 갖게 되는데

날아가지 말아야하는 정보는 차라리 user.permissions에 만들어야 한다는 의미다.

authenticate 하여 권한을 획득한 user도 req.permissions를 사용할 때가 있다.

- 회원 로그인 했는데, 비회원때 작성한 비밀글을 읽을 경우가 대표적인 예

따라서, 현재 권한을 배정하는 일이 매우 일회적인 권한 획득이면 req.permissions에서 권한 검증이 있어야 한다.

또한 회원의 특별한 권한은 user.permissions에서 이루어져야 한다.

그룹권한은 user.roles 에서 검증이 되어야 한다.