La visualisation de documents intégrée doit donner l’impression de faire partie de l’application, et non d’un transfert vers une ancienne extension de navigateur ou un programme de bureau installé localement. Pour les projets ASP.NET et .NET sous Windows, Doconut fournit un SDK de visualisation de documents capable de rendre les documents métier directement dans votre application web.

Ce guide explique l’architecture d’une expérience de visualisation sans plugin sans présenter le code source non documenté de Doconut.

Documents traversant un service de rendu .NET vers un visualiseur intégré sans plugin

Ce que signifie « sans plugin »

Un visualiseur sans plugin ne demande pas à l’utilisateur final d’installer des technologies telles qu’ActiveX, Flash, Silverlight ou une extension de navigateur personnalisée avant d’ouvrir un document.

Cela réduit plusieurs sources de friction :

Les utilisateurs n’ont pas besoin d’autorisations d’installation locale.
Les équipes informatiques n’ont pas à distribuer et mettre à jour un plugin côté client.
L’application conserve le flux de visualisation dans son propre interface.
Les dépendances aux plugins hérités ne deviennent pas une condition d’ouverture d’un fichier.

« Sans plugin » ne signifie pas « sans dépendance ». Le serveur a toujours besoin du SDK approprié, du runtime, des polices, de l’accès au stockage, de la configuration et de la licence. L’application reste également responsable de l’authentification, de l’autorisation, de la conservation et de la surveillance.

Pourquoi le rendu de documents côté serveur est utile

Les documents métier sont plus complexes que le contenu web ordinaire. Les fichiers Office, les dessins CAD, les messages électroniques et les images haute résolution nécessitent chacun un traitement sensible au format.

Un composant .NET côté serveur peut gérer ce traitement tandis que l’application web présente l’expérience de visualisation résultante. Cela évite de demander à chaque utilisateur d’installer le logiciel d’édition d’origine.

Doconut est conçu pour ce rôle. Ses informations produit actuelles décrivent la prise en charge de types de documents tels que PDF, documents Office, dessins CAD, fichiers e‑mail et images. Vérifiez les formats exacts et les fonctionnalités requises par votre application sur la page Doconut Viewer.

Planifier le flux de visualisation

Une demande de document sécurisée suit généralement ces étapes :

L’utilisateur sélectionne un document à l’aide d’un identifiant d’application.
ASP.NET authentifie la requête.
Le serveur vérifie l’accès à ce document précis.
L’application résout l’emplacement de stockage protégé.
Le document est transmis à la couche de visualisation via la méthode d’intégration prise en charge.
L’application enregistre le résultat et libère les ressources temporaires.

Le client ne doit jamais recevoir les informations d’identification du stockage, les chemins serveur non restreints ou plus d’informations sur le document que la session autorisée ne nécessite.

Utiliser les limites de sécurité standard d’ASP.NET

La page de visualisation doit être protégée comme toute autre ressource sensible.

Les mécanismes .NET standards peuvent inclure :

Middleware d’authentification
L’attribut [Authorize]
Politiques d’autorisation et revendications
Autorisation basée sur les ressources
Injection de dépendances pour les services de stockage et de visualisation
Journalisation structurée avec filtrage des données sensibles

L’autorisation doit être évaluée sur le serveur. Masquer une action de barre d’outils ou une route dans l’interface utilisateur n’empêche pas un client déterminé de la demander directement.

Garder l’accès au SDK derrière un service d’application

Évitez de disperser les appels spécifiques au visualiseur dans les contrôleurs et les pages. Un service d’application dédié peut :

Résoudre les identifiants de documents autorisés
Ouvrir un Stream contrôlé
Appliquer la configuration pour la version du SDK installée
Libérer les ressources de fichier et de flux
Convertir les échecs techniques en erreurs d’application sécurisées
Enregistrer les temps d’exécution et les diagnostics assainis

Cette frontière rend l’application plus facile à tester et réduit l’impact des futures mises à jour du SDK.

Utilisez les ressources officielles de téléchargement et de documentation de Doconut pour l’installation des packages et les directives d’API spécifiques à chaque version.

Construire un hôte de visualiseur utile

Le conteneur du visualiseur appartenant à l’application doit disposer de suffisamment d’espace pour les documents réels. Évitez les cartes étroites et les largeurs fixes de bureau.

.viewer-workspace {
  display: grid;
  grid-template-rows: auto minmax(0, 1fr);
  width: 100%;
  min-height: 36rem;
  height: calc(100dvh - 4rem);
}

.viewer-host {
  min-width: 0;
  min-height: 0;
  overflow: hidden;
}

Il s’agit de CSS standard pour la page environnante, pas d’une configuration Doconut. Ne ciblez pas de sélecteurs internes non documentés et n’inventez pas d’options SDK.

La page doit également fournir :

Un état de chargement clair
Un message d’erreur sécurisé
Un titre de document visible
Un moyen de revenir au flux parent
Des contrôles d’application accessibles
Un espace suffisant pour les feuilles de calcul larges et les dessins détaillés

Valider les documents avant le rendu

Si les utilisateurs téléversent des fichiers, vérifiez :

La taille du fichier
L’extension et la signature du fichier
Le format pris en charge
Les exigences de mot de passe ou de chiffrement
Les restrictions spécifiques à l’entreprise
Le nom de stockage généré par le serveur

Ne construisez pas les chemins serveur directement à partir du nom de fichier d’origine. Stockez un identifiant d’application sûr et résolvez‑le via un service côté serveur autorisé.

Préparer le serveur Windows

Le comportement de rendu peut dépendre de l’environnement du serveur. Confirmez :

Les versions Windows et .NET prises en charge
Les polices requises
L’emplacement de stockage temporaire et ses autorisations
Les ressources CPU, mémoire et capacité disque disponibles
La taille maximale des documents et le nombre de sessions concurrentes
La configuration de licence
Les procédures de nettoyage

Testez des documents clients représentatifs sur un environnement qui correspond à la production.

Checklist de sécurité et de confidentialité

Avant la mise en production :

Authentifiez les requêtes de visualisation lorsque cela est requis.
Autorisez l’utilisateur pour le document spécifique.
Conservez les chemins de stockage et les identifiants sur le serveur.
Restreignez les autorisations des fichiers temporaires.
Définissez la rétention des originaux, des données temporaires et des exportations.
Assainissez les erreurs affichées aux utilisateurs.
Excluez le contenu des documents et les secrets des journaux.
Appliquez des limites de téléversement et de concurrence.
Maintenez le SDK et les dépendances de l’application à jour.

Les affirmations de conformité doivent refléter l’ensemble du système déployé et les processus de votre organisation, pas seulement un composant UI isolé.

Tester au‑delà du chemin heureux

Votre bibliothèque de tests doit inclure :

PDFs multi‑pages
Grandes feuilles de calcul
Dessins CAD détaillés
Présentations avec des polices peu communes
Fichiers e‑mail avec pièces jointes
Grandes images
Fichiers endommagés et non pris en charge
Requêtes non autorisées
Sessions de visualisation concurrentes
Requêtes interrompues et redémarrages d’application

Vérifiez que les échecs ne révèlent pas les chemins serveur, les traces de pile ou les URL de stockage.

Où Doconut s’insère

Doconut fournit la capacité de visualisation de documents intégrée au sein d’une application web .NET. Votre application fournit la sécurité, le stockage, le flux de travail, la mise en page réactive et les contrôles opérationnels environnants.

Cette séparation permet aux équipes de remplacer les flux de travail dépendants de plugins hérités sans prétendre que la gestion des documents devient sans effort ou sans responsabilité.

Explorez le SDK de visualiseur de documents .NET de Doconut vérifié, puis utilisez la page de téléchargement officielle pour les instructions correspondant à la version que vous avez sélectionnée.

Conclusion

Une expérience de document sans plugin réduit les frictions d’installation et garde les utilisateurs à l’intérieur de votre application. Construisez‑la sur un flux de documents autorisé par le serveur, isolez l’accès au SDK, fournissez un hôte de visualiseur spacieux et testez des fichiers réels sous une charge similaire à la production.

Pour les applications ASP.NET et .NET sous Windows, Doconut peut fournir la couche de visualisation de documents tandis que votre équipe conserve le contrôle de l’application et du cycle de vie des documents.

Ce que signifie « sans plugin »