Tutorial: Controlar el acceso a la impresión con Doconut
8/21/2026

Tutorial: Controlar el acceso a la impresión con Doconut

Una guía paso a paso sobre la impresión con Doconut, autorización propia de la aplicación, controles del visor y pruebas sin depender de fragmentos de API inventados.

El catálogo oficial de funciones de Doconut enumera la impresión desde el navegador y la exportación a PDF como capacidades del visor. Controlar el acceso a ellas aún requiere dos decisiones separadas: si Doconut muestra la acción correspondiente y si la aplicación anfitriona autoriza esa operación para el usuario y documento actuales.

Una ruta de impresión de documento que termina en una puerta de autorización controlada
Una ruta de impresión de documento que termina en una puerta de autorización controlada

Para conocer los controles exactos que admite la versión instalada, comience con la documentación de Doconut y los ejemplos empaquetados disponibles en la página oficial de descarga de Doconut. No copie claves de configuración ni código fuente de una versión no relacionada o de un artículo no verificado.


1. Definir la política de impresión primero

Anote quién puede imprimir y bajo qué condiciones antes de modificar la barra de herramientas. Una política útil responde preguntas como:

  • ¿Se permite la impresión para todos los visores, solo ciertos roles o documentos específicos?
  • ¿Depende la decisión del inquilino, estado del caso, clasificación del documento o fecha de expiración?
  • ¿Se requiere una marca de agua en la salida imprimible?
  • ¿Deben registrarse los eventos de impresión?
  • ¿Puede un usuario imprimir una revisión anterior del documento?
  • ¿Qué debe ocurrir cuando el permiso cambia mientras la vista previa está abierta?

Evite un único Boolean global cuando la regla real es contextual. Modele la impresión como una operación propia para que pueda autorizarse de forma independiente de la visualización y descarga.

2. Separar el estado de la UI de la autorización

La página anfitriona puede decidir si muestra un control de impresión después de recibir el resultado de un permiso propio de la aplicación. Eso mejora la claridad para los usuarios que no pueden imprimir.

Sin embargo, ocultar un control no constituye un límite de autorización. Un usuario aún puede llamar directamente a un endpoint conocido, reproducir una solicitud anterior o invocar la impresión del navegador sobre contenido visible. Cada ruta del servidor que genere salida imprimible debe aplicar la misma política.

Utilice estados distintos en la UI:

EstadoComportamiento del visorComportamiento del servidor
Impresión permitidaMostrar la acción de impresión soportadaAutorizar y crear la salida solicitada
Impresión denegadaOcultar o desactivar la acción con una explicación claraDevolver una respuesta prohibida
Política desconocidaMantener la acción no disponible mientras se carga el permisoNo crear salida
Sesión expiradaPedir al usuario que se vuelva a autenticarRechazar la solicitud obsoleta

3. Proteger el endpoint de impresión

Proteja la operación de la aplicación que invoca la impresión o devuelve la salida imprimible. La decisión de autorización debe tener en cuenta la pertenencia al inquilino, la propiedad, la clasificación, el estado del flujo de trabajo y la revisión del documento. Resuelva el documento en el servidor en lugar de aceptar una ruta o URL de almacenamiento suministrada por el cliente.

Si su aplicación imprime a través de una ruta específica del visor en lugar de crear un PDF, aplique la misma autorización antes de invocar esa ruta.

4. Configurar la versión del visor instalado

Una vez que exista la regla del servidor, configure la UI de Doconut usando la opción exacta documentada para el paquete y los archivos de ejemplo enviados con su versión. Las demostraciones en vivo de Doconut le permiten observar el comportamiento del visor soportado antes de comprometerse con una integración concreta. Verifique:

  1. Dónde se establece la opción: configuración del servidor, modelo de vista o inicialización del cliente.
  2. Si oculta un elemento de la barra de herramientas, desactiva una acción o afecta la salida generada.
  3. Si el valor se aplica por instancia del visor o globalmente.
  4. Si la impresión y la exportación son operaciones separadas.
  5. Si una actualización cambió el nombre de la opción o su valor predeterminado.

Trate el ejemplo oficial como la fuente de verdad. Un nombre de propiedad que parezca plausible no es evidencia suficiente de que el visor instalado lo reconozca.

5. Manejar la impresión del navegador de forma honesta

Una configuración del visor no puede garantizar que la información visible nunca se imprima o capture. El navegador puede imprimir la página anfitriona, y los usuarios pueden tomar capturas de pantalla o fotografías. La interceptación de teclado y el CSS específico para impresión pueden mejorar la experiencia esperada, pero son medidas que pueden eludirse del lado del cliente.

Si la página anfitriona no debe producir una copia impresa útil, su aplicación puede usar su propia presentación específica para impresión y reemplazar la vista previa con un mensaje explicativo. Mantenga ese comportamiento de la página anfitriona separado de los controles documentados del visor de Doconut.

No describa esto como protección de documento. Use renderizado del lado del servidor, autorización, exportaciones controladas y marcas de agua visibles cuando su evaluación de riesgos requiera una disuasión más fuerte.

6. Mantener descarga, exportación e impresión separadas

Los usuarios y desarrolladores a menudo tratan estas acciones como un único interruptor “solo lectura”, pero representan flujos de datos diferentes:

  • Ver muestra el contenido renderizado.
  • Descargar devuelve el archivo fuente u otro archivo almacenado.
  • Exportar crea un formato derivado.
  • Imprimir produce una representación imprimible o invoca la impresión del navegador.

Autorice cada operación explícitamente. Un usuario que no pueda imprimir puede seguir teniendo permiso para descargar, o viceversa. Su barra de herramientas debe reflejar las decisiones del servidor en lugar de definirlas.

7. Añadir eventos de auditoría útiles

Si la impresión es sensible, registre la decisión sin guardar el documento mismo. Un evento puede incluir el usuario, inquilino, identificador del documento, revisión, resultado de la política, marca de tiempo e ID de correlación.

Registre tanto intentos exitosos como denegados. Si el servicio de impresión crea un archivo temporal, también registre si su limpieza se completó. Mantenga rutas de archivo, tokens, títulos de documentos que contengan datos personales y contenido imprimible fuera de los registros rutinarios.

8. Probar más allá del botón faltante

La barra de herramientas es solo la primera afirmación. Añada pruebas para toda la operación:

Usuario autorizado

  • La acción de impresión prevista es visible.
  • La solicitud de impresión tiene éxito para un documento permitido.
  • Se utiliza la revisión correcta.
  • Las marcas requeridas aparecen en la salida generada.
  • El evento de auditoría registra el éxito.

Usuario no autorizado

  • La acción está ausente o deshabilitada.
  • Una solicitud directa al endpoint de impresión devuelve una respuesta prohibida.
  • Cambiar el ID del documento no elude la regla.
  • Una URL copiada de una sesión autorizada no puede reutilizarse indebidamente.
  • La denegación no revela si otro inquilino posee el documento.

Cambios de estado

  • El permiso revocado durante una sesión se aplica en la siguiente solicitud de impresión.
  • Una sesión expirada no puede imprimir.
  • Un documento eliminado o sustituido produce un error controlado.
  • La salida de impresión temporal sigue la regla de retención configurada.

La automatización del navegador puede verificar el estado visible y el código de respuesta. Las pruebas de integración deben validar la evaluación de la política y la autorización a nivel de documento de forma independiente.

Preguntas frecuentes

¿Ocultar el botón de imprimir detiene el atajo de impresión del navegador?
No. Solo elimina una acción prevista del visor si el visor instalado implementa ese comportamiento. La impresión del navegador y la captura de pantalla requieren consideraciones separadas y no pueden evitarse completamente con código del cliente.

¿Debe incluirse el permiso de impresión en la URL de visualización?
Prefiera una decisión de autorización del lado del servidor vinculada al usuario autenticado, al documento y a la operación. Si una referencia temporal lleva permisos, delimítela estrechamente, protéjala de registros y referenciadores, y revalide las acciones sensibles.

¿Es suficiente desactivar la impresión para documentos confidenciales?
No. Es solo un control de usabilidad o disuasión. Los flujos confidenciales también necesitan protección de almacenamiento, autorización a nivel de objeto, exportaciones controladas, reglas de retención, monitoreo y un modelo aceptado de riesgo residual.

Conclusión

Una implementación confiable del control de impresión de Doconut comienza en el servidor y termina en la interfaz. Defina la política, proteja la operación, configure solo la opción documentada para su visor instalado, explique el resultado a los usuarios y pruebe tanto las solicitudes directas como la visibilidad de la barra de herramientas. Utilice la página oficial de funciones, la documentación, las descargas y las demostraciones como fuentes de implementación en lugar de recrear el código del producto en el artículo.