Supprimer le bouton de téléchargement peut soutenir un flux de travail en lecture seule, mais cela ne rend pas un document visible impossible à copier. Une implémentation sécurisée nécessite une autorisation côté serveur, un stockage protégé, des sessions de courte durée, une journalisation rigoureuse et une compréhension honnête de ce que les restrictions de l’interface utilisateur peuvent réellement accomplir.
Doconut fournit un visualiseur de documents .NET intégré pour les applications métier. Ce tutoriel explique la conception de sécurité qui l’entoure sans publier de propriétés de configuration devinées ni d’autres sources de code non documentées de Doconut.
1. Définir ce que signifie « lecture seule »
Commencez par une politique précise. Différentes équipes peuvent interpréter « lecture seule » ainsi :
- Ne pas proposer le fichier original en téléchargement.
- Ne pas afficher d’action d’exportation.
- Ne pas autoriser l’impression.
- Autoriser la visualisation uniquement pendant une session autorisée.
- Empêcher les utilisateurs d’accéder directement à l’emplacement de stockage.
- Ajouter des enregistrements d’audit lorsqu’un document est ouvert.
Ce sont des contrôles distincts. Décidez lesquels sont requis et vérifiez que le produit Doconut que vous avez choisi, ses plugins et votre licence prennent en charge le comportement du visualiseur dont vous avez besoin.
Ne promettez jamais qu’un document visible ne puisse pas être capturé. Les captures d’écran, les caméras, les outils d’accessibilité, les capacités du navigateur et l’accès autorisé aux pixels affichés rendent impossible une prévention absolue.
2. Protéger le fichier original
Le document original doit rester dans un stockage protégé côté serveur.
Utilisez :
- Des identifiants de document générés par le serveur
- Des permissions de stockage restreintes
- Le chiffrement au repos lorsque nécessaire
- Une politique de rétention documentée
- Des permissions séparées pour le téléversement, la visualisation, l’exportation et l’administration
N’envoyez jamais les informations d’identification du stockage, les chemins de fichiers non restreints ou des URL publiques permanentes au client.
3. Autoriser chaque requête de document
Dans ASP.NET Core, protégez la route du visualiseur avec les mécanismes d’authentification et d’autorisation standards.
Le serveur doit vérifier :
- Que l’utilisateur est authentifié.
- Que le document existe.
- Que l’utilisateur est autorisé à visualiser ce document précis.
- Que l’action demandée est permise pour le rôle de l’utilisateur et l’état actuel du flux de travail.
L’attribut [Authorize] peut protéger une route, tandis que les politiques, les revendications ou l’autorisation basée sur les ressources peuvent prendre la décision spécifique au document.
L’autorisation doit également couvrir tout point de terminaison qui renvoie des données de document, des pages, des exportations, des annotations ou des sorties d’impression. Sécuriser uniquement la page initiale laisse d’autres routes exposées.
4. Séparer les permissions de visualisation et de téléchargement
Modélisez les permissions explicitement plutôt que de les déduire d’un bouton masqué.
Par exemple :
CanViewDocumentCanDownloadOriginalCanExportDocumentCanPrintDocumentCanManageDocument
Ces noms décrivent les politiques d’application, pas les API Doconut. Votre couche d’autorisation doit les évaluer côté serveur avant d’exécuter l’action correspondante.
Un administrateur peut disposer de la permission de téléchargement tandis qu’un autre utilisateur authentifié ne possède que la permission de visualisation. Les deux utilisateurs peuvent partager la même page d’application tout en recevant des capacités autorisées différentes.
5. Configurer le visualiseur à partir de la documentation officielle
Utilisez uniquement les noms de configuration et les étapes d’intégration documentés pour la version exacte de Doconut installée dans votre application.
La page officielle du visualiseur Doconut fournit les informations produit actuelles. La page de téléchargement et documentation Doconut propose les ressources d’installation et les exemples spécifiques à chaque version.
Si le produit installé expose un paramètre pris en charge pour masquer ou désactiver une action de téléchargement :
- Appliquez‑le conformément à la documentation officielle.
- Considérez‑le comme un contrôle d’interface utilisateur et de flux de travail.
- Gardez le point de terminaison serveur associé protégé.
- Testez que les utilisateurs non autorisés ne peuvent pas le contourner avec une requête directe.
Ne copiez pas de propriétés de configuration devinées à partir d’un article non lié et ne supposez pas qu’elles sont prises en charge.
6. Garder l’intégration du visualiseur derrière un service
Un service d’application dédié peut :
- Résoudre le document autorisé
- L’ouvrir via une abstraction de stockage approuvée
- Appliquer la configuration du visualiseur prise en charge
- Libérer les flux et ressources temporaires
- Enregistrer des événements d’audit assainis
- Retourner des erreurs sécurisées au contrôleur
Cela maintient les détails spécifiques au SDK hors des politiques d’autorisation et du code de présentation.
Des types .NET standards tels que Stream, FileStream, CancellationToken et les services injectés peuvent former la frontière de l’application. Suivez la documentation propre à Doconut pour les appels au SDK.
7. Appliquer la défense en profondeur
Un flux de travail en lecture seule peut inclure :
- Authentification et autorisation au niveau des ressources
- Isolation réseau et stockage
- Durée de session courte
- Routes d’exportation et d’impression restreintes
- Filigrane lorsqu’il est pris en charge et approprié
- Événements d’audit pour l’accès aux documents
- Limites de débit et contrôles de concurrence
- Règles claires de rétention et de nettoyage
- Surveillance de sécurité pour les modèles d’accès inhabituels
Aucun contrôle unique n’est suffisant. Un bouton masqué sans protection serveur est particulièrement facile à contourner.
8. Journaliser l’accès sans divulguer de données
Les champs d’audit utiles comprennent :
- Identifiant du document dans l’application
- Identifiant de l’utilisateur autorisé
- Horodatage
- Action demandée
- Résultat
- Identifiant de corrélation
- Raison assainie du refus ou de l’échec
Évitez de journaliser :
- Le contenu du document
- Les informations d’identification du stockage
- Les jetons d’accès
- Les URL sensibles
- Les chemins serveur complets
- Les informations personnelles inutiles
Protégez les journaux d’audit en fonction de leur sensibilité et des exigences de rétention.
9. Tester les tentatives de contournement de l’interface
Ne vous arrêtez pas après avoir confirmé l’absence d’un bouton de barre d’outils.
Testez si un utilisateur en lecture seule peut :
- Demander directement la route du fichier original
- Appeler une route d’exportation ou d’impression
- Modifier un identifiant de document
- Réutiliser une session expirée
- Accéder au document d’un autre utilisateur
- Découvrir des URL de stockage dans le balisage ou les réponses réseau
- Provoquer des erreurs détaillées révélant des chemins internes
- Conserver l’accès après la révocation de sa permission
Incluez à la fois des tests d’autorisation automatisés et des tests manuels dans le navigateur.
10. Fixer des attentes utilisateur précises
Expliquez ce que la politique fait :
- Elle limite les flux de travail de téléchargement ou d’exportation fournis par l’application.
- Elle restreint l’accès aux utilisateurs autorisés.
- Elle peut enregistrer les événements de visualisation.
- Elle garde le fichier original derrière des contrôles serveur.
Expliquez également ce qu’elle ne peut pas garantir :
- Elle ne peut pas empêcher la photographie ou les captures d’écran dans tous les environnements.
- Elle ne peut pas révoquer l’information déjà vue et mémorisée.
- Elle ne remplace pas les contrôles contractuels, organisationnels ou de sécurité des points de terminaison.
Cette distinction rend le produit plus fiable et aide les parties prenantes à choisir les contrôles appropriés pour du matériel hautement sensible.
Checklist de vérification
- La visualisation et le téléchargement utilisent des permissions serveur séparées.
- Chaque requête de document effectue une autorisation au niveau de la ressource.
- Le fichier original n’a aucune URL publique permanente.
- Les paramètres du visualiseur proviennent de la documentation de la version installée de Doconut.
- Les actions masquées ont des points de terminaison serveur protégés.
- Les données temporaires disposent d’un processus de nettoyage défini.
- Les journaux d’audit évitent le contenu du document et les secrets.
- Les requêtes directes non autorisées sont couvertes par les tests.
- Les réponses d’erreur n’exposent pas les détails internes du stockage.
- Le texte promotionnel ne prétend pas une prévention absolue de copie.
Où Doconut s’insère
Doconut fournit la couche de visualisation intégrée au sein de l’application .NET. Votre application reste responsable de l’identité, de l’autorisation, des permissions, du stockage, de la rétention, de l’audit et de la véracité de la promesse « lecture seule ».
Évaluez le SDK du visualiseur de documents .NET Doconut en fonction de vos exigences de sécurité et de vos documents représentatifs. Utilisez les ressources officielles pour les configurations prises en charge plutôt que de vous fier à du code source deviné.
Conclusion
Un flux de travail de document en lecture seule est une conception de défense en profondeur, pas un simple drapeau booléen. Protégez le fichier original, autorisez chaque requête, séparez les permissions de visualisation et de téléchargement, validez les paramètres du visualiseur pris en charge, auditez les accès et testez les tentatives de contournement directes.
Avec ces contrôles en place, Doconut peut offrir l’expérience de document intégré tandis que votre application ASP.NET applique la politique de sécurité qui l’entoure.