Capacidades de despliegue y de aplicación
Meratyn tiene dos contratos de autoridad deliberadamente separados. Las capacidades de despliegue describen lo que una instalación alojada permite exponer; los roles y privilegios de aplicación describen lo que una persona, un espacio de trabajo o un host incrustado puede hacer dentro de ese despliegue. Ninguno sustituye la autenticación ni las reglas de autorización del servicio que respalda los datos.
Política de despliegue
MAPPVIEW_CAPABILITIES es una política opcional, separada por comas, que leen
el runtime web y el sidecar de procesamiento. Las capacidades de despliegue
admitidas son:
| Valor | Controla |
|---|---|
project:edit | Comandos de edición del proyecto y cambios propios del proyecto |
data:add | Fuentes de Añadir datos |
processing:run | Comandos de Procesamiento |
export:data | Comandos de exportación de datos y proyectos |
plugins:install | Instalación y gestión de complementos |
settings:manage | Cambios de configuración y del administrador de estilos |
Si la variable está ausente o vacía, el despliegue conserva el valor local
completo. none no concede ninguna capacidad de despliegue. Los demás valores
se recortan y deduplican; los valores desconocidos se ignoran, de modo que una
lista explícita formada solo por valores desconocidos queda bloqueada. La
paleta de comandos y los atajos aplican la misma política que los menús
visibles, y la ejecución vuelve a comprobarla para impedir que un comando
obsoleto eluda el límite de despliegue.
El procesamiento que usa el sidecar Python requiere la capacidad de despliegue
processing:run y el privilegio de aplicación específico processing:sidecar.
El propio sidecar comprueba también la política de despliegue y responde HTTP
403 antes de despachar una operación cuando el procesamiento no está permitido.
Es un control global del despliegue, no una comprobación de acceso por usuario.
En Docker, publique el valor tanto en la configuración de runtime de Vite como en el entorno del sidecar. Los despliegues de escritorio e incrustados usan el mismo contrato. Los diseños de quiosco y aula pueden seguir usando perfiles de interfaz para la presentación, combinados con esta política para la autoridad.
Roles y privilegios de aplicación
El store de capacidades de aplicación comienza con el rol administrator,
salvo que un host proporcione otra política. Los roles integrados son:
| Rol | Privilegios incluidos |
|---|---|
viewer | export:data, export:image |
editor | Guardar proyectos, añadir capas locales/remotas, editar capas, ejecutar procesamiento en cliente y exportar datos/imágenes |
publisher | Privilegios de editor más compartir proyectos (incluidos enlaces públicos), procesamiento con sidecar y uso del asistente |
administrator | Todos los privilegios de aplicación |
custom | Vacío hasta que un host conceda privilegios individuales |
Los nombres de privilegio individuales son project:save, project:share,
project:share-public, layers:add-local, layers:add-remote, layers:edit,
processing:run, processing:sidecar, export:data, export:image,
plugins:install, assistant:use, connections:manage, settings:manage,
embed:access y scripting:execute. Un host puede intersectar políticas,
conceder o revocar un privilegio y asociar a cada privilegio una explicación de
denegación sin datos sensibles. Elegir un rol integrado reemplaza las
concesiones manuales y las explicaciones antiguas.
Los menús y la paleta de comandos omiten las acciones que la política de
aplicación actual no permite. Las llamadas directas de documento, embed y
scripting siguen llegando al mismo límite tipado y devuelven un resultado
AuthorizationDenied/authorization-denied sin exponer credenciales ni
detalles de infraestructura. Use el panel Diagnóstico y el mensaje de
denegación de la operación para distinguir una decisión de política de un
servicio ausente o un fallo del runtime.