동기화 게이트웨이의 역할은 사용자 및 채널보다 사용하기가 더 복잡해 보이기 때문에 간과되는 경우가 많습니다. 그러나 역할은 추상화 계층을 하나 더 제공하며 데이터 모델을 크게 단순화할 수 있습니다. 도시별 레스토랑 리뷰를 공유하는 애플리케이션을 예로 들어 보겠습니다. 진행자, 게스트 사용자 등 사용자마다 다른 권한을 가질 수 있습니다. 이 자습서에서는 동기화 기능 를 사용하여 해당 애플리케이션의 인증된 사용자가 승인, 리뷰 게시 또는 다른 사용자에게 역할을 할당할 수 있도록 허용합니다.
애플리케이션에는 총 3가지 유형의 역할이 있습니다:
- 레벨 1사용자가 레벨 1 역할은 리뷰를 게시할 수 있지만, 리뷰는 사용자가 레벨 3 역할(예: 진행자)을 공개로 설정합니다.
- 레벨 2사용자는 운영자의 확인 없이 리뷰를 게시할 수 있습니다. 즉, 사용자는 승인을 받지 않고도 댓글을 게시할 수 있습니다.
- 레벨 3사용자가 리뷰를 승인하거나 거부할 수 있습니다.시작하겠습니다!
동기화 게이트웨이 다운로드
동기화 게이트웨이를 다운로드하고 파일의 압축을 풉니다:
https://www.couchbase.com/downloads?family=sync-gateway
동기화 게이트웨이 바이너리를 찾을 수 있습니다. bin 폴더에 있는 구성 파일의 예와 예제 폴더로 이동합니다. 폴더를 복사합니다. users-role.json 파일을 프로젝트의 루트에 추가합니다:
|
1 |
cp ~/다운로드/카우치베이스-동기화-게이트웨이/예제/사용자-역할.json /경로/에/프로젝트/동기화-게이트웨이-구성.json |
다음 섹션에서는 구성 파일을 업데이트하여 사용자와 역할을 만들 수 있도록 합니다.
구성 파일 편집
In 동기화 게이트웨이-config.json를 클릭하고 읽을 DB 개체를 업데이트합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
{ "log": ["*"], "데이터베이스": { "db": { "서버": "월러스:", "users": { "jens": { "admin_roles": ["level-1"], "비밀번호": "letmein" }, "andy": { "admin_roles": ["level-2"], "비밀번호": "letmein" }, "william": { "admin_roles": [], "비밀번호": "letmein" }, "traun": { "admin_roles": ["level-3"], "비밀번호": "letmein" } }, "역할": { "level-1": {}, "level-2": {}, "level-3": {} }, } } } |
위에서 몇 가지 일이 일어나고 있습니다:
- 사용자를 만듭니다.
jens를 사용하여레벨 1역할. - 사용자를 만듭니다.
andy를 사용하여레벨 2역할. - 사용자를 만듭니다.
william아무런 역할 없이. - 사용자를 만듭니다.
traun를 사용하여레벨 3역할. - 3가지 역할을 정의합니다. 사용자와 마찬가지로 역할도 관리 REST API 또는 구성 파일에서 명시적으로 만들어야 합니다.
역할 생성 시 참고 사항
역할을 만드는 가장 쉬운 방법은 위에서 한 것처럼 구성 파일에서 만드는 것입니다.
역할을 만드는 또 다른 방법은 관리자 REST API를 사용하는 것입니다. 애플리케이션에서 해당 역할을 만들 수 있는 엔드포인트를 노출하는 경우 앱 서버에 요청(파란색 화살표)을 보내 역할을 만들고 성공하면 201 Created(녹색 화살표)를 반환하여 역할을 동적으로 만들 수 있습니다.
다음 섹션에서는 세 가지 유형의 문서에 대한 쓰기 및 읽기 작업을 처리하는 동기화 함수를 추가합니다(레스토랑, 리뷰, 프로필).
동기화 기능 추가하기
역할 그리고 사용자 에 대한 액세스 권한을 부여할 수 있습니다. 채널. 사용자에게 역할을 부여하고 해당 역할에 대한 모든 채널 액세스 권한을 상속할 수 있습니다.
채널 액세스는 사용자의 읽기 보안을 결정합니다. 쓰기 보안은 채널을 기반으로 할 수도 있습니다( requireAccess), 사용자/역할을 기반으로 할 수도 있습니다(요구 사용자 그리고 요구 역할) 또는 문서 콘텐츠( throw).
문서에 대한 읽기 및 쓰기 권한은 독립적입니다. 실제로 쓰기 권한은 전적으로 동기화 함수에 의해 제어됩니다. 동기화 함수가 수정본을 거부하지 않는 한, 클라이언트는 모든 문서를 수정할 수 있습니다. 모든 require* 함수는 유효성 검사기 역할을 할 뿐만 아니라 쓰기 액세스 API 역할도 합니다.
동기화 기능으로 많은 채널을 생성하는 것은 매우 흔한 일입니다. 이는 아주 좋은 현상입니다. 하지만 각 사용자를 차례로 채널에 할당하는 것은 번거로울 수 있습니다. 대신 역할을 사용할 수 있습니다!
이를 한 번 더 숙지하면 사용자에게 역할을 부여하고 해당 역할에 대한 채널 액세스 권한을 상속할 수 있습니다.
즉, 역할을 할당하는 것만으로 사용자에게 여러 채널에 대한 액세스 권한을 부여할 수 있습니다. 모든 사용자를 채널에 할당할 필요가 없으므로 매우 강력한 기능입니다. 역할에 채널에 대한 액세스 권한을 부여하고 사용자를 역할에 할당하기만 하면 됩니다.
이를 염두에 두고 다음에서 동기화 기능을 교체하세요. 동기화 게이트웨이-config.json:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
함수(doc, oldDoc) { 만약 (doc.유형 == "레스토랑"){ 채널(doc.restaurant_id); } else 만약 (doc.유형 == "review") { 스위치(doc.역할) { case "level-1": // 1단계 요구 역할(doc.역할); var 채널명 = doc.소유자 + "-in-review"; 채널(채널명); 액세스(doc.소유자, 채널명); 액세스("role:level-3", 채널명); break; case "level-2": // 2단계 요구 역할(doc.역할); 채널(doc.restaurant_id); break; case "level-3": // 3단계 요구 역할(doc.역할); 채널(doc.restaurant_id); break; } } else 만약 (doc.유형 == "프로필") { 요구 역할("level-3"); 역할(doc.이름, "role:" + doc.역할); } } |
현재 상황은 다음과 같습니다:
- 다음을 보유한 사용자 레벨 1 역할에 쓰기 권한이 있는 이유는
채널함수를 호출합니다. 그런 다음 해당 사용자와 레벨 3 이 채널에 액세스할 수 있습니다. 바로 이 부분에서 역할의 힘이 빛을 발합니다. 역할에 액세스 권한을 부여하면 해당 역할을 가진 모든 사용자에게 채널에 대한 액세스 권한을 부여하는 것입니다. 호출요구 역할를 입력하면 쓰기 권한이 부여됩니다. - 문서 유형
리뷰에 의해 생성된 레벨 2 역할: 문서는 문서가 속한 레스토랑과 동일한 채널로 이동해야 합니다. 호출은요구 역할를 입력하면 쓰기 권한이 부여됩니다. - 문서 유형
리뷰에 의해 생성된 레벨 3 역할: 해당 레스토랑의 채널에 문서가 들어가야 합니다. 레벨 3 사용자는 또한 모든{사용자 이름}-검토 중채널에 액세스할 수 있습니다. 다른 사용자의 보류 중인 리뷰를 승인/거부할 수 있습니다.
업데이트된 구성 파일로 동기화 게이트웨이를 시작합니다:
|
1 |
$ ~/다운로드/카우치베이스-동기화-게이트웨이/bin/동기화 게이트웨이 /경로/에/프로젝트/동기화-게이트웨이-구성.json |
이 예에서는 역할의 3가지 주요 기능을 활용하고 있습니다:
- 채널에 대한 역할 액세스 권한을 부여하고 해당 역할을 가진 모든 사용자에게 간접적으로 액세스 권한을 부여합니다.
- 요구 역할을 사용하여 쓰기 권한을 부여합니다.
- 사용자에게 역할 할당하기.
이제 다음 HTTP 요청을 통해 동기화 함수가 예상대로 작동하는지 테스트할 수 있습니다.
다양한 시나리오 실행
시나리오 1
문서 유형 리뷰 에 의해 생성된 레벨 1 사용자: 문서는 {사용자 이름}-검토 중 채널과 레벨 3 역할도 이 채널에 액세스할 수 있어야 합니다.
사용자로 로그인 jens:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
curl -vX POST -H '콘텐츠 유형: 애플리케이션/json' :4984/db/세션 -d '{"name": "jens", "password": "letmein"}' > POST /db/세션 HTTP/1.1 > 사용자-에이전트: curl/7.37.1 > 호스트: :4984 > 수락: */* > 콘텐츠-유형: 애플리케이션/json > 콘텐츠-길이: 39 > * 업로드 완전히 보낸 꺼짐: 39 out 의 39 바이트 < HTTP/1.1 200 확인 < 콘텐츠-길이: 103 < 콘텐츠-유형: 애플리케이션/json * 서버 카우치베이스 동기화 게이트웨이/1.1.0 는 not 블랙리스트 < 서버: 카우치베이스 동기화 게이트웨이/1.1.0 < 설정-쿠키: 동기화 게이트웨이 세션=6c52b8cd2c706d55e97d9606058c0abd90a5d200; 경로=/db/; 만료=화요일, 07 7월 2015 08:23:03 UTC < 날짜: 월, 06 7월 2015 08:23:03 GMT < * 연결 #0에서 호스트까지 그대로 유지됨 {"인증_핸들러":["default","쿠키"],"ok":true,"userCtx":{"채널":{"!":1},"name":"jens"}}⏎ |
새 문서 유형 저장 리뷰 (토큰을 반환된 토큰으로 대체하십시오. 설정-쿠키 헤더):
|
1 2 3 4 |
curl -vX POST -H '콘텐츠 유형: 애플리케이션/json' --쿠키 'SyncGatewaySession=d007ceb561f0111512c128040c32c02ea9d90234' :4984/db/ -d '{"type": "리뷰", "역할": "level-1", "owner": "jens"}' |
- 해당 사용자 확인
jens채널에 액세스할 수 있습니다.jens-in-review를 클릭하면 댓글 문서가 그 안에 있습니다.
- 해당 사용자 확인
traun채널에 액세스할 수 있습니다.jens-in-review.
이 문서가 속한 채널과 해당 문서에 액세스할 수 있는 역할/사용자를 다음에서 볼 수도 있습니다. 문서 탭을 클릭합니다:
시나리오 2
역할을 사용하여 쓰기 권한 부여하기.
다음 계정으로 로그인 andy 를 클릭하고 로그인 요청에서 반환받은 토큰으로 토큰을 교체합니다.
|
1 2 3 4 |
curl -vX POST -H '콘텐츠 유형: 애플리케이션/json' --쿠키 'SyncGatewaySession=6e7ce145ae53c83de436b47ae37d8d94beebebea' :4984/db/ -d '{"type": "리뷰", "역할": "level-2", "owner": "andy", "restaurant_id": "123"}' |
- 댓글이 레스토랑 채널에 추가되었는지 확인합니다(
123이 예에서는).
시나리오 3
사용자에게 역할 할당하기.
다음 계정으로 로그인 traun 를 클릭하고 로그인 요청에서 반환받은 토큰으로 토큰을 교체합니다.
|
1 2 3 4 |
curl -vX POST -H '콘텐츠 유형: 애플리케이션/json' --쿠키 'SyncGatewaySession=3a5c5a67ff67643f8ade175363c65354584429e9' :4984/db/ -d '{"type": "프로필", "이름": "william", "role": "level-3"}' |
- 다음 사항을 확인하십시오.
william역할이 있습니다.레벨 3. - 다음 사항을 확인하십시오.
william에 액세스 할 수 있습니다.jens-in-review채널.
결론
이 튜토리얼에서는 채널과 requireRole을 사용하여 동적으로 유효성을 검사하고 쓰기 작업을 수행하는 방법을 배웠습니다. 또한 역할 API를 사용하여 여러 사용자에게 한 번에 여러 채널을 할당했습니다.
