Ajouter la visualisation de documents à une application métier implique plus que placer un PDF dans une iframe. Les fichiers Office, les dessins CAD, les fichiers e‑mail et les images nécessitent des capacités de rendu différentes, tandis que l’application doit toujours contrôler l’authentification, le stockage, l’autorisation et la conservation.
Doconut est un SDK de visualisation de documents .NET conçu pour intégrer le rendu et l’interaction de documents dans les applications web. Au lieu de présenter une recette de code source non vérifiée, ce guide explique les décisions d’intégration que votre équipe doit prendre et identifie les composants .NET standards qui entourent généralement le SDK.
Pourquoi un visualiseur intégré diffère d’un téléchargement de fichier
Un point de terminaison de téléchargement transfère le fichier original et laisse l’expérience de visualisation à un logiciel extérieur à votre application. Un visualiseur intégré maintient l’utilisateur au sein de votre produit et peut offrir un espace cohérent pour la navigation, la recherche, la révision et d’autres fonctionnalités activées.
Construire vous‑même la couche de rendu est difficile car chaque format a ses propres règles :
- Les fichiers PDF peuvent contenir des polices intégrées, des annotations, des formulaires et des ensembles de pages très volumineux.
- Les fichiers Word, Excel et PowerPoint nécessitent une mise en page soignée et une gestion précise des polices.
- Les dessins CAD nécessitent un redimensionnement précis, des calques et un zoom détaillé.
- Les formats e‑mail et image introduisent des pièces jointes, des métadonnées, des questions de couleur et de résolution.
Un SDK dédié permet à l’équipe de développement de se concentrer sur le contrôle d’accès, les flux de travail et l’expérience utilisateur au lieu de maintenir un moteur de rendu séparé pour chaque format pris en charge.
Étape 1 : Confirmer les formats et fonctionnalités requis
Commencez par un inventaire réel des fichiers que vos utilisateurs ouvrent. Séparez les formats essentiels des formats occasionnels et enregistrez des échantillons représentatifs pour les tests.
Votre liste de contrôle pourrait inclure :
- Documents PDF et XPS
- Documents de traitement de texte
- Feuilles de calcul
- Présentations
- Dessins CAD
- Fichiers e‑mail
- Formats d’image courants
Identifiez ensuite les fonctionnalités importantes pour chaque flux de travail. La visualisation, la recherche de texte, les annotations, l’impression et la conversion sont des capacités différentes et peuvent nécessiter différents composants Doconut ou licences.
Examinez la portée actuelle du produit sur la page du visualiseur Doconut vérifiée avant de vous engager sur un format ou une fonctionnalité. Les capacités du produit peuvent évoluer, ainsi vos tests d’acceptation doivent rester l’autorité finale concernant les documents réellement utilisés par vos clients.
Étape 2 : Choisir où les documents entrent dans l’application
Une application ASP.NET peut recevoir des documents provenant de plusieurs sources contrôlées :
- Un téléchargement géré comme un
IFormFileASP.NET Core - Un emplacement de fichier protégé
- Une base de données ou un référentiel de gestion de documents
- Un stockage d’objets accessible par le serveur
- Un service interne qui renvoie un
Stream
Le flux de visualisation doit utiliser une référence de document autorisée par le serveur. Ne placez pas de informations d’identification de stockage, de chemins de fichiers non restreints ou d’URL publiques permanentes dans le balisage côté client.
Si les utilisateurs téléversent des fichiers, validez‑les avant le rendu. Vérifiez la taille du fichier, l’extension, la signature du fichier et toute restriction spécifique à l’entreprise. Conservez l’identifiant généré par le serveur plutôt que de faire confiance au nom de fichier original comme chemin.
Étape 3 : Définir l’authentification et l’autorisation
L’application — et non l’interface du visualiseur — doit décider qui est autorisé à ouvrir un document.
Dans ASP.NET Core, les mécanismes standard tels que le middleware d’authentification, l’attribut [Authorize], les politiques, les revendications et l’autorisation basée sur les ressources peuvent protéger le point de terminaison qui lance une session de visualisation. La décision d’autorisation doit inclure à la fois l’utilisateur actuel et le document demandé.
Un flux de requête sécurisé ressemble à ceci :
- L’utilisateur demande un document en utilisant un identifiant au niveau de l’application.
- Le serveur authentifie l’utilisateur.
- Le serveur vérifie que l’utilisateur peut accéder à ce document spécifique.
- Le serveur résout l’emplacement de stockage protégé.
- Le visualiseur ne reçoit que les informations requises pour cette session autorisée.
Ne supposez jamais que masquer un bouton de barre d’outils constitue un contrôle d’autorisation. Les vérifications d’accès côté serveur restent nécessaires même lorsque les contrôles de téléchargement ou d’impression ne sont pas affichés.
Étape 4 : Ajouter Doconut via ses ressources d’intégration officielles
Utilisez le package actuel et les instructions d’installation fournis par Doconut. La page de téléchargement Doconut vérifiée donne accès aux ressources d’intégration NuGet, à la documentation, aux exemples et aux démonstrations.
La configuration exacte peut dépendre de :
- Le type de votre application ASP.NET ou .NET
- Le produit Doconut sélectionné et ses plugins
- La version de Doconut
- Votre licence
- Les formats de documents et les fonctionnalités que vous activez
- La configuration de votre serveur Windows
Suivez la documentation correspondant à la version installée. Évitez de copier des extraits d’initialisation provenant d’articles de blog non liés, car les espaces de noms, la configuration, les chemins des ressources et les API peuvent changer d’une version à l’autre.
Étape 5 : Créer une frontière de visualisation dédiée
Gardez la visualisation de documents derrière un petit service d’application plutôt que d’appeler les fonctionnalités du SDK dans les contrôleurs et les composants UI.
Ce service peut être responsable de :
- Résoudre un identifiant de document autorisé
- Ouvrir le document en tant que
Streamcontrôlé lorsque cela est approprié - Fournir la configuration de visualisation requise
- Libérer les ressources de fichier et de flux
- Traduire les échecs techniques en erreurs d’application sécurisées
- Enregistrer les métriques opérationnelles sans consigner le contenu des documents
Cette frontière facilite les mises à jour et réduit le risque d’exposer les détails de stockage à la couche de présentation. Elle offre également aux tests un endroit clair pour substituer une implémentation sécurisée.
Étape 6 : Concevoir la page du visualiseur
Le visualiseur doit disposer de suffisamment d’espace pour être utile. Une carte étroite entourée de contrôles non liés rend difficile l’inspection de grandes feuilles de calcul et de dessins CAD.
Planifiez la page autour de :
- Une hauteur de visualiseur stable
- Des états de chargement, vide et d’erreur clairs
- Un titre de document concis
- Des contrôles environnants accessibles au clavier
- Une mise en page qui ne masque pas les contrôles importants du visualiseur
- Un moyen explicite de revenir au flux de travail parent
Testez avec des noms de fichiers longs, de grands nombres de pages, des feuilles de calcul larges, des dessins détaillés et des documents qui ne se rendent pas. L’état d’erreur ne doit pas divulguer les chemins du serveur, les traces d’exception ou les URL de stockage.
Étape 7 : Gérer les fichiers et les données temporaires
Définissez une politique de rétention avant le déploiement. Considérez séparément le fichier original, les données de rendu temporaires, les caches, les exportations, les annotations et les journaux.
Des mesures de protection utiles incluent :
- Un répertoire temporaire dédié avec des permissions restreintes
- Des noms uniques générés par le serveur
- Nettoyage après les sessions terminées et échouées
- Un processus planifié pour les fichiers temporaires abandonnés
- Des quotas de stockage et une surveillance
- Le chiffrement au repos lorsque requis par votre politique de sécurité
Rendez le nettoyage observable. Si la suppression échoue silencieusement, les fichiers temporaires peuvent s’accumuler et devenir à la fois un problème opérationnel et de sécurité.
Étape 8 : Configurer les protections en production
Le rendu de documents peut consommer du CPU, de la mémoire et de l’espace disque temporaire. Protégez l’application avec des limites explicites :
- Taille maximale de téléchargement
- Nombre maximal de travaux de rendu concurrents
- Délais d’attente des requêtes et du traitement
- Limites de file d’attente lorsque le rendu est effectué de façon asynchrone
- Quotas de stockage temporaire
- Vérifications de santé et surveillance structurée des erreurs
Pour des charges de travail importantes ou imprévisibles, isolez le rendu des processus d’application sensibles à la latence. Mesurez avec des documents similaires à ceux des clients plutôt qu’en vous basant uniquement sur de petits fichiers de test.
Étape 9 : Tester le flux complet
Un test d’intégration réussi doit couvrir plus que « la première page est apparue ».
Testez :
- Chaque format de fichier requis
- Fichiers petits, grands, multi‑pages et endommagés
- Documents avec des polices peu communes
- Fichiers protégés par mot de passe lorsque votre flux de travail les prend en charge
- Utilisateurs autorisés et non autorisés
- Sessions de visualisation concurrentes
- Redémarrages de l’application et requêtes interrompues
- Nettoyage après succès et échec
- Fonctionnalités du visualiseur incluses dans la configuration du produit que vous avez sélectionnée
Conservez une collection versionnée de documents de test assainis. Réexécutez‑la lors de la mise à jour de Doconut, .NET, Windows Server, l’infrastructure de stockage ou les dépendances associées.
Checklist de sécurité
Avant la publication, confirmez que :
- Toute requête de visualisation nécessite une authentification le cas échéant.
- L’autorisation est vérifiée pour le document spécifique.
- Les entrées contrôlées par l’utilisateur ne peuvent pas devenir un chemin de fichier serveur non restreint.
- Les informations d’identification de stockage n’atteignent jamais le client.
- Les limites de téléchargement et la validation sont activées.
- Les fichiers temporaires ont un accès restreint et une politique de nettoyage testée.
- Les journaux excluent le contenu des documents, les secrets et les URL sensibles.
- Les messages d’erreur affichés aux utilisateurs sont assainis.
- Le SDK et les dépendances de l’application suivent un processus de mise à jour.
Les contrôles du visualiseur peuvent soutenir votre flux de travail métier, mais ils ne peuvent pas empêcher toutes les formes de capture une fois l’information visible à un utilisateur autorisé. Utilisez‑les conjointement avec les contrôles d’accès et une politique de protection de l’information appropriée.
Où Doconut s’insère
Doconut fournit la capacité de visualisation de documents à l’intérieur de l’application .NET, tandis que votre application reste responsable de l’identité, de l’autorisation, du stockage des fichiers, de la rétention, de l’audit et du flux de travail environnant.
Cette division des responsabilités offre aux équipes .NET un chemin pratique pour prendre en charge les documents métier sans construire plusieurs moteurs de rendu à partir de zéro. Elle maintient également les détails d’intégration spécifiques au produit liés à la documentation officielle de la version que vous déployez.
Explorez le SDK du visualiseur de documents .NET Doconut, puis utilisez les ressources officielles de téléchargement et de documentation pour l’évaluer avec vos propres documents.
Conclusion
Un visualiseur de documents intégré fiable commence par des exigences de format claires et un flux de documents côté serveur sécurisé. Validez les entrées, autorisez chaque requête de document, isolez l’accès au SDK derrière un service d’application, planifiez le nettoyage des fichiers temporaires et testez avec des fichiers réalistes.
Avec ces bases en place, Doconut peut fournir la couche de visualisation pour votre application web .NET sous Windows, tandis que votre équipe conserve le contrôle de l’architecture de l’application et du cycle de vie des documents.