Agregar la visualización de documentos a una aplicación empresarial implica más que colocar un PDF en un iframe. Los archivos de Office, los dibujos CAD, los correos electrónicos y las imágenes requieren diferentes capacidades de renderizado, mientras que la aplicación aún necesita controlar la autenticación, el almacenamiento, la autorización y la retención.
Doconut es un SDK de visor de documentos .NET diseñado para incrustar la renderización e interacción de documentos en aplicaciones web. En lugar de presentar una receta de código fuente no verificada, esta guía explica las decisiones de integración que su equipo debe tomar e identifica los componentes estándar de .NET que comúnmente rodean al SDK.
Por qué un visor incrustado es diferente de una descarga de archivo
Un punto final de descarga transfiere el archivo original y deja la experiencia de visualización a software externo a su aplicación. Un visor incrustado mantiene al usuario dentro de su producto y puede proporcionar un lugar consistente para la navegación, búsqueda, revisión y otras funciones habilitadas.
Construir la capa de renderizado por cuenta propia es difícil porque cada formato tiene sus propias reglas:
- Los archivos PDF pueden contener fuentes incrustadas, anotaciones, formularios y conjuntos de páginas muy extensos.
- Los archivos de Word, Excel y PowerPoint requieren un manejo cuidadoso del diseño y las fuentes.
- Los dibujos CAD necesitan escalado preciso, capas y zoom detallado.
- Los formatos de correo electrónico e imagen introducen archivos adjuntos, metadatos, color y consideraciones de resolución.
Un SDK dedicado permite que el equipo de la aplicación se centre en el control de acceso, los flujos de trabajo y la experiencia del usuario en lugar de mantener un renderizador separado para cada formato admitido.
Paso 1: Confirmar los formatos y características requeridos
Comience con un inventario real de los archivos que sus usuarios abren. Separe los formatos esenciales de los ocasionales y registre muestras representativas para pruebas.
Su lista de verificación podría incluir:
- Documentos PDF y XPS
- Documentos de procesamiento de texto
- Hojas de cálculo
- Presentaciones
- Dibujos CAD
- Archivos de correo electrónico
- Formatos de imagen comunes
Luego identifique las características que importan para cada flujo de trabajo. Visualización, búsqueda de texto, anotaciones, impresión y conversión son capacidades diferentes y pueden requerir distintos componentes o licencias de Doconut.
Revise el alcance actual del producto en la verificada página del visor Doconut antes de comprometerse con un formato o característica. Las capacidades del producto pueden cambiar, por lo que sus pruebas de aceptación deben seguir siendo la autoridad final para los documentos que sus clientes realmente usan.
Paso 2: Elegir dónde ingresan los documentos a la aplicación
Una aplicación ASP.NET puede recibir documentos de varias fuentes controladas:
- Una carga manejada como un
IFormFilede ASP.NET Core - Una ubicación de archivo protegida
- Una base de datos o repositorio de gestión de documentos
- Almacenamiento de objetos al que accede el servidor
- Un servicio interno que devuelve un
Stream
El flujo de visualización debe usar una referencia de documento autorizada por el servidor. No coloque credenciales de almacenamiento, rutas de archivo sin restricciones o URLs públicas permanentes en el marcado del cliente.
Si los usuarios cargan archivos, valídelos antes de renderizarlos. Verifique el tamaño del archivo, la extensión, la firma del archivo y cualquier restricción específica del negocio. Almacene el identificador generado por el servidor en lugar de confiar en el nombre original del archivo como ruta.
Paso 3: Definir autenticación y autorización
La aplicación —no la interfaz del visor— debe decidir quién puede abrir un documento.
En ASP.NET Core, los mecanismos estándar como el middleware de autenticación, el atributo [Authorize], políticas, reclamaciones y autorización basada en recursos pueden proteger el punto final que inicia una sesión de visualización. La decisión de autorización debe incluir tanto al usuario actual como al documento solicitado.
Un flujo de solicitud seguro se ve así:
- El usuario solicita un documento usando un identificador a nivel de aplicación.
- El servidor autentica al usuario.
- El servidor verifica que el usuario pueda acceder a ese documento específico.
- El servidor resuelve la ubicación de almacenamiento protegida.
- El visor recibe solo la información requerida para esa sesión autorizada.
Nunca asuma que ocultar un botón de la barra de herramientas es un control de autorización. Las comprobaciones de acceso del lado del servidor siguen siendo necesarias incluso cuando los controles de descarga o impresión no se muestran.
Paso 4: Añadir Doconut a través de sus recursos oficiales de integración
Utilice el paquete actual y las instrucciones de configuración suministradas por Doconut. La verificada página de descarga de Doconut brinda acceso a recursos de integración de NuGet, documentación, ejemplos y demostraciones.
La configuración exacta puede depender de:
- El tipo de su aplicación ASP.NET o .NET
- El producto Doconut seleccionado y sus complementos
- La versión de Doconut
- Su licencia
- Los formatos de documento y características que habilite
- La configuración de su servidor Windows
Siga la documentación que coincida con la versión instalada. Evite copiar fragmentos de inicialización de publicaciones de blogs no relacionadas porque los espacios de nombres, la configuración, las rutas de recursos y las API pueden cambiar entre versiones.
Paso 5: Crear un límite dedicado para la visualización
Mantenga la visualización de documentos detrás de un pequeño servicio de aplicación en lugar de llamar a la funcionalidad del SDK en todos los controladores y componentes de UI.
Ese servicio puede ser responsable de:
- Resolver un identificador de documento autorizado
- Abrir el documento como un
Streamcontrolado cuando corresponda - Proveer la configuración de visualización requerida
- Liberar recursos de archivo y de flujo
- Traducir fallas técnicas en errores de aplicación seguros
- Registrar métricas operativas sin registrar el contenido de los documentos
Este límite facilita las actualizaciones y reduce el riesgo de exponer detalles de almacenamiento a la capa de presentación. También brinda a las pruebas un lugar claro para sustituir una implementación segura.
Paso 6: Diseñar la página del visor
El visor debe disponer de suficiente espacio para ser útil. Una tarjeta estrecha rodeada de controles no relacionados dificulta la inspección de hojas de cálculo grandes y dibujos CAD.
Planifique la página alrededor de:
- Una altura de visor estable
- Estados claros de carga, vacío y error
- Un título de documento conciso
- Controles circundantes accesibles mediante el teclado
- Un diseño que no oculte controles importantes del visor
- Una forma explícita de volver al flujo de trabajo padre
Pruebe con nombres de archivo largos, gran número de páginas, hojas de cálculo anchas, dibujos detallados y documentos que no se puedan renderizar. El estado de error no debe revelar rutas del servidor, rastros de excepciones ni URLs de almacenamiento.
Paso 7: Gestionar archivos y datos temporales
Defina una política de retención antes del despliegue. Considere por separado el archivo original, los datos temporales de renderizado, cachés, exportaciones, anotaciones y registros.
Medidas de protección útiles incluyen:
- Un directorio temporal dedicado con permisos restringidos
- Nombres únicos generados por el servidor
- Limpieza después de sesiones completadas y fallidas
- Un proceso programado para archivos temporales abandonados
- Cuotas de almacenamiento y monitoreo
- Cifrado en reposo donde lo requiera su política de seguridad
Haga que la limpieza sea observable. Si la eliminación falla silenciosamente, los archivos temporales pueden acumularse y convertirse en un problema operativo y de seguridad.
Paso 8: Configurar salvaguardas de producción
La renderización de documentos puede consumir CPU, memoria y espacio de disco temporal. Proteja la aplicación con límites explícitos:
- Tamaño máximo de carga
- Máximo de trabajos de renderizado concurrentes
- Timeouts de solicitud y procesamiento
- Límites de cola cuando la renderización se realiza de forma asíncrona
- Cuotas de almacenamiento temporal
- Chequeos de salud y monitoreo estructurado de errores
Para cargas de trabajo grandes o impredecibles, aísle la renderización de los procesos de aplicación sensibles a la latencia. Mida con documentos similares a los de producción en lugar de basarse solo en archivos de prueba pequeños.
Paso 9: Probar el flujo de trabajo completo
Una prueba de integración exitosa debe cubrir más que “apareció la primera página”.
Pruebe:
- Cada formato de archivo requerido
- Archivos pequeños, grandes, multipágina y dañados
- Documentos con fuentes poco comunes
- Archivos protegidos con contraseña cuando su flujo de trabajo los soporte
- Usuarios autorizados y no autorizados
- Sesiones de visualización concurrentes
- Reinicios de la aplicación y solicitudes interrumpidas
- Limpieza después de éxitos y fallas
- Funciones del visor incluidas en la configuración del producto seleccionado
Mantenga una colección versionada de documentos de prueba sanitizados. Vuelva a ejecutarla al actualizar Doconut, .NET, Windows Server, la infraestructura de almacenamiento o dependencias relacionadas.
Lista de verificación de seguridad
Antes del lanzamiento, confirme que:
- Cada solicitud de visualización requiere autenticación cuando corresponde.
- Se verifica la autorización para el documento específico.
- La entrada controlada por el usuario no pueda convertirse en una ruta de archivo del servidor sin restricciones.
- Las credenciales de almacenamiento nunca llegan al cliente.
- Se habilitan límites y validación de cargas.
- Los archivos temporales tienen acceso restringido y una política de limpieza probada.
- Los registros excluyen contenidos de documentos, secretos y URLs sensibles.
- Los mensajes de error mostrados a los usuarios están sanitizados.
- El SDK y las dependencias de la aplicación siguen un proceso de actualización.
Los controles del visor pueden respaldar su flujo de trabajo empresarial, pero no pueden impedir toda forma de captura una vez que la información es visible para un usuario autorizado. Úselos junto con controles de acceso y una política de protección de la información adecuada.
Dónde encaja Doconut
Doconut proporciona la capacidad de visualización de documentos dentro de la aplicación .NET, mientras que su aplicación sigue siendo responsable de la identidad, autorización, almacenamiento de archivos, retención, auditoría y el flujo de trabajo circundante.
Esta división de responsabilidades brinda a los equipos .NET una ruta práctica para soportar documentos empresariales sin construir múltiples motores de renderizado desde cero. También mantiene los detalles de integración específicos del producto vinculados a la documentación oficial de la versión que despliegue.
Explore el SDK de visor de documentos .NET de Doconut, luego use los recursos oficiales de descarga y documentación para evaluarlo con sus propios documentos.
Conclusión
Un visor de documentos incrustado y fiable comienza con requisitos de formato claros y un flujo de documento seguro del lado del servidor. Valide las entradas, autorice cada solicitud de documento, aísle el acceso al SDK detrás de un servicio de aplicación, planifique la limpieza de archivos temporales y pruebe con archivos realistas.
Con esos cimientos, Doconut puede suministrar la capa de visualización para su aplicación web .NET basada en Windows mientras su equipo mantiene el control de la arquitectura de la aplicación y del ciclo de vida de los documentos.