Doconut est enregistré de la même manière que tout le reste dans ASP.NET Core : un service dans le conteneur et un middleware dans le pipeline. Il hérite de votre authentification, de votre journalisation, de votre graphe d’injection de dépendances et de votre scénario de déploiement, car il s’exécute à l’intérieur de ceux‑ci plutôt qu’à côté.
Le problème
La plupart des visionneuses de documents arrivent comme un service séparé. Cela signifie une deuxième unité de déploiement, un deuxième ensemble d’identifiants, un saut réseau que vos documents doivent traverser, et une deuxième chose à réveiller quelqu’un à 2 h du matin.
Doconut est une bibliothèque. AddDoconut() l’ajoute à votre collection de services ; UseDoconut() l’insère dans votre pipeline. Il s’exécute sous l’identité de votre processus, voit votre configuration, écrit dans votre journal, et est déployé par ce qui déploie déjà votre application.
La conséquence pratique est que l’autorisation reste à sa place. Vous appelez OpenDocumentAsync() après votre propre vérification de permission, et la visionneuse ne peut rendre que ce que vous avez décidé de lui fournir.
Capacités
La visionneuse n’est pas liée à un style d’hébergement. Rendu le div de montage depuis une vue Razor ou une page statique et ouvrez le document depuis une action de contrôleur, un gestionnaire de page ou un point de terminaison mappé.
Parce que les points de terminaison vivent dans votre pipeline, [Authorize] fonctionne comme toujours. Il n’y a pas de second système d’identité avec lequel se fédérer.
La sécurité des documents repose sur l’état de session ASP.NET, c’est pourquoi UseSession() doit être enregistré avant UseDoconut(). Cela signifie que la notion de qui vous êtes par la visionneuse est la même que celle de l’application.
Plusieurs nœuds derrière un équilibreur de charge partagent le cache de rendu, ainsi une session ouverte sur un nœud continue de fonctionner lorsque la requête suivante atterrit ailleurs.
IIS, Kestrel, ou une image de conteneur que vous construisez vous‑même. Rien dans l’intégration ne change entre eux, sauf l’endroit où le fichier de licence est monté.
Avec le plugin Converter, DocumentConverter.ConvertAsync() s’exécute dans le même processus — pas de second service, pas de téléchargement temporaire, pas de aller‑retour.
Intégration
UserMayRead et ResolvePath sont votre propre code. C’est le but : Doconut n’apprend jamais quels documents existent ou qui est autorisé à les voir.
Plateformes prises en charge
// Program.cs
builder.Services.AddDoconut(options =>
{
options.LicensePath = "Doconut.Viewer.lic";
});
builder.Services.AddSession(); // document security rides on session state
var app = builder.Build();
app.UseSession(); // call UseSession() before UseDoconut()
app.UseDoconutResources(); // must be registered before UseDoconut()
app.UseDoconut();
// Open the document server-side, behind your own authorization
app.MapPost("/api/open", async (Viewer viewer, HttpContext ctx, string documentId) =>
{
if (!await ctx.UserMayRead(documentId))
return Results.Forbid();
// The token is opaque — hand it to the widget, never log or persist it.
string token = await viewer.OpenDocumentAsync(ResolvePath(documentId));
return Results.Ok(new { token });
}).RequireAuthorization();Détails
Oui. Les deux sont pris en charge et utilisent la même architecture DI + middleware. Il existe des pages dédiées pour chaque version si vous avez besoin de détails spécifiques.
Non, et c’est intentionnel. L’intégration est toujours middleware plus le widget JavaScript, ce qui maintient la même intégration valide sur Razor Pages, MVC, Web Forms et Blazor au lieu de se fragmenter en quatre.
Les fermes Web et le déploiement distribué sont pris en charge via un cache de rendu partagé. Un document ouvert sur un nœud reste lisible lorsque des requêtes ultérieures atteignent un autre.
Non. Le rendu est natif — il n’y a aucune interopérabilité Office, aucun Word sans tête, et aucune automatisation COM à surveiller.
Blazor
Rendu côté serveur avec un widget qui s'installe proprement dans le cycle de vie de l'interop Blazor — Server et WebAssembly tous deux pris en charge.
BlazorWord
Rendu natif DOC/DOCX/RTF/ODT sans installation d'Office, sans interop COM et sans automatisation côté serveur.
WordUne licence temporaire prend quelques minutes à demander et s'exécute entièrement sur votre propre machine. Les fichiers qui comptent sont ceux qui posent déjà problème à votre visionneuse actuelle.