Los roles en Sync Gateway a menudo se pasan por alto porque parecen más complejos de usar que los usuarios y los canales. Sin embargo, proporcionan una capa adicional de abstracción y pueden simplificar enormemente su modelo de datos. Tomemos el ejemplo de una aplicación para compartir reseñas de restaurantes por ciudades. Diferentes usuarios podrían tener diferentes privilegios como moderadores y usuarios invitados. En este tutorial, configurará el Función de sincronización para permitir que los usuarios autenticados de dicha aplicación aprueben, publiquen revisiones o asignen funciones a otros usuarios.
En total, habrá 3 tipos de funciones en la aplicación:
- nivel 1: usuarios con el nivel 1 pueden publicar reseñas, pero deben ser aceptadas por usuarios con el rol nivel 3 (es decir, moderadores) sea pública.
- nivel 2: los usuarios pueden publicar comentarios sin necesidad de validación por parte de los moderadores. Esto significa que pueden publicar un comentario sin necesidad de aprobación.
- nivel 3Los usuarios pueden aprobar o rechazar las opiniones.
Descargar Sync Gateway
Descargue Sync Gateway y descomprima el archivo:
https://www.couchbase.com/downloads?family=sync-gateway
Encontrará el binario Sync Gateway en la carpeta papelera y ejemplos de archivos de configuración en la carpeta ejemplos carpeta. Copie la carpeta usuarios-role.json en la raíz del proyecto:
|
1 |
cp ~/Descargas/couchbase-sincronizar-pasarela/ejemplos/usuarios-papeles.json /ruta/a/proj/sincronizar-pasarela-config.json |
En la siguiente sección, actualizarás el archivo de configuración para crear usuarios y roles.
Editar el archivo de configuración
En sync-gateway-config.jsonactualiza el objeto db a leer:
|
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": ["*"], "bases de datos": { "db": { "servidor": "morsa:", "usuarios": { "jens": { "admin_roles": ["nivel-1"], "contraseña": "letmein" }, "andy": { "admin_roles": ["nivel-2"], "contraseña": "letmein" }, "william": { "admin_roles": [], "contraseña": "letmein" }, "traun": { "admin_roles": ["nivel-3"], "contraseña": "letmein" } }, "roles": { "nivel-1": {}, "nivel-2": {}, "nivel-3": {} }, } } } |
Arriba están pasando un par de cosas:
- Se crea el usuario
jenscon elnivel 1papel. - Se crea el usuario
andycon elnivel 2papel. - Se crea el usuario
williamsin ningún papel. - Se crea el usuario
trauncon elnivel 3papel. - Usted define los 3 roles. Al igual que los usuarios, los roles deben crearse explícitamente en la API REST de Admin o en el archivo de configuración.
Nota sobre la creación de roles
La forma más fácil de crear roles es en el archivo de configuración como se hizo anteriormente.
Otra forma de crear roles es a través de la API REST del administrador. Siempre que exponga un punto final para crear esos roles desde la aplicación, puede crear roles dinámicamente enviando una solicitud al servidor de su aplicación (flechas azules), que creará el rol y devolverá un 201 Creado si ha tenido éxito (flechas verdes).
En la siguiente sección, añadirá la función de sincronización para gestionar las operaciones de escritura y lectura de los tres tipos diferentes de documentos (restaurante, revise, perfil).
Añadir la función de sincronización
Funciones y usuarios pueden tener acceso a canales. A los usuarios se les pueden otorgar roles, y heredar cualquier acceso al canal para esos roles.
El acceso al canal determina la seguridad de lectura de un usuario. La seguridad de escritura también puede basarse en canales (utilizando requireAccess), pero también puede basarse en el usuario/rol (requerirUsuario y requireRole), o el contenido del documento (mediante tirar).
El acceso de lectura y escritura a los documentos es independiente. De hecho, el acceso de escritura está totalmente gobernado por su función de sincronización: a menos que la función de sincronización rechace la revisión, un cliente puede modificar cualquier documento. Todas las funciones require* actúan como validadores, pero también como API de acceso a la escritura.
Es muy común ver que la función de sincronización crea montones y montones de canales. Esto está muy bien. Sin embargo, puede resultar engorroso asignar cada usuario a un canal. En su lugar, puedes utilizar un rol.
Deja que esto se hunda una vez más, a los usuarios se les pueden conceder roles y heredar cualquier acceso al canal para esos roles.
Esto significa que puedes conceder a un usuario acceso a múltiples canales simplemente asignándole un rol. Esto es muy potente porque no necesitas asignar cada usuario a un canal. Basta con conceder a la función acceso al canal y asignar los usuarios a la función.
Teniendo esto en cuenta, sustituye la función de sincronización en sync-gateway-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 |
función(doc, oldDoc) { si (doc.tipo == "restaurante"){ canal(doc.restaurant_id); } si no si (doc.tipo == "revisión") { interruptor(doc.papel) { caso "nivel-1": // Paso 1 requireRole(doc.papel); var channelname = doc.propietario + "-en revisión"; canal(channelname); acceda a(doc.propietario, channelname); acceda a("role:level-3", channelname); romper; caso "nivel-2": // Paso 2 requireRole(doc.papel); canal(doc.restaurant_id); romper; caso "nivel-3": // Paso 3 requireRole(doc.papel); canal(doc.restaurant_id); romper; } } si no si (doc.tipo == "perfil") { requireRole("nivel-3"); papel(doc.nombre, "rol:" + doc.papel); } } |
Esto es lo que ocurre:
- Los usuarios con el nivel 1 tiene acceso de escritura porque llama al rol
canalfunción. A continuación, conceda a ese usuario y al nivel 3 acceso a este canal. Aquí es donde el poder de los roles realmente brilla. Al otorgar acceso a un rol, estás otorgando acceso al canal a todos los usuarios con ese rol. La llamada arequireRoleconcederá el permiso de escritura. - Documentos de tipo
revisecreado por un nivel 2 rol: el documento debe ir en el mismo canal que el restaurante al que pertenece. La llamada arequireRoleconcederá el permiso de escritura. - Documentos de tipo
revisecreado por un nivel 3 función: el documento debe ir en el canal correspondiente a ese restaurante. nivel 3 también tienen acceso de lectura a todos los{nombre_usuario}-en-revisióncanales. Pueden aprobar/rechazar las revisiones pendientes de otros usuarios.
Inicie Sync Gateway con el archivo de configuración actualizado:
|
1 |
$ ~/Descargas/couchbase-sincronizar-pasarela/papelera/sync_gateway /ruta/a/proj/sincronizar-pasarela-config.json |
En este ejemplo, está utilizando las 3 características principales de los roles:
- Conceder a un rol acceso a un canal e indirectamente a todos los usuarios con ese rol.
- Concesión de permisos de escritura mediante un requireRole.
- Asignar un rol a un usuario.
Ahora puede probar que la Función de Sincronización se comporta como se espera con las siguientes peticiones HTTP.
Ejecución de diferentes escenarios
Escenario 1
Documentos de tipo revise creado por un nivel 1 usuario: el documento debe ir en el {nombre_usuario}-en-revisión y los usuarios con el nivel 3 papel también debería tener acceso a este canal.
Iniciar sesión como usuario jens:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
rizo -vX POST -H Content-Type: application/json' :4984/db/_sesión -d '{"nombre": "jens", "contraseña": "letmein"}' > POST /db/_sesión HTTP/1.1 > Usuario-Agente: rizo/7.37.1 > Anfitrión: :4984 > Acepte: */* > Contenido-Tipo: aplicación/json > Contenido-Longitud: 39 > * cargar completamente enviado fuera de: 39 fuera de 39 bytes < HTTP/1.1 200 OK < Contenido-Longitud: 103 < Contenido-Tipo: aplicación/json * Servidor Couchbase Sincroniza Pasarela/1.1.0 es no En la lista negra < Servidor: Couchbase Sincroniza Pasarela/1.1.0 < Establecer-Galleta: SyncGatewaySession=6c52b8cd2c706d55e97d9606058c0abd90a5d200; Ruta=/db/; Expira en=Mar, 07 Julio 2015 08:23:03 UTC < Fecha: Lun, 06 Julio 2015 08:23:03 GMT < * Conexión #0 a host intacto {"authentication_handlers":["por defecto","cookie"],"ok":verdadero,"userCtx":{"canales":{"!":1},"nombre":"jens"}}⏎ |
Guardar un nuevo documento de tipo revise (sustituya el token por el devuelto en la función Set-Cookie encabezamiento anterior):
|
1 2 3 4 |
rizo -vX POST -H Content-Type: application/json' --galleta 'SyncGatewaySession=d007ceb561f0111512c128040c32c02ea9d90234' :4984/db/ -d '{"tipo": "revisión", "rol": "level-1", "owner": "jens"}' |
- Compruebe que el usuario
jenstiene acceso al canaljens-en-revisióny el documento de comentarios está ahí.
- Compruebe que el usuario
trauntiene acceso al canaljens-en-revisión.
También puede ver los canales a los que pertenece este documento y los roles/usuarios que tienen acceso a él en la sección Documentos ficha:
Escenario 2
Conceder acceso de escritura mediante un rol.
Iniciar sesión como andy y sustituye el token por el que recibiste de la solicitud de inicio de sesión.
|
1 2 3 4 |
rizo -vX POST -H Content-Type: application/json' --galleta 'SyncGatewaySession=6e7ce145ae53c83de436b47ae37d8d94beebebea' :4984/db/ -d '{"tipo": "revisión", "rol": "level-2", "owner": "andy", "restaurant_id": "123"}' |
- Compruebe que el comentario se ha añadido al canal del restaurante (denominado
123en este ejemplo).
Escenario 3
Asignar un rol a un usuario.
Iniciar sesión como traun y sustituye el token por el que recibiste de la solicitud de inicio de sesión.
|
1 2 3 4 |
rizo -vX POST -H Content-Type: application/json' --galleta 'SyncGatewaySession=3a5c5a67ff67643f8ade175363c65354584429e9' :4984/db/ -d '{"tipo": "perfil", "nombre": "william", "role": "level-3"}' |
- Compruebe que
williamtiene papelnivel 3. - Compruebe que
williamtiene acceso aljens-en-revisióncanal.
Conclusión
En este tutorial, aprendiste a usar canales y requireRole para validar y realizar operaciones de escritura dinámicamente. También asignaste múltiples canales a la vez a múltiples usuarios usando la API de roles.
