Doconut‑visare är ett .NET-dokumentvisningsbibliotek designat för att placera PDF, Office, CAD, bild och andra stödda dokumentfamiljer i en applikation. En solid Doconut-integration handlar mindre om att hitta den kortaste kodsnutten och mer om att välja en ren gräns mellan din applikation, visaren och webbläsaren.

En inbäddad dokumentförhandsgranskning placerad i en strukturerad webbapplikationsarbetsyta

Doconut dokumentationsnav länkar till de underhållna installationsvägarna för stödda .NET-projekttyper. Använd guiden som matchar versionen installerad i din applikation, och behandla sedan den omgivande sidan, identitetskontrollerna och åtkomstflödet som applikationskod som ditt team äger.

Börja med integrationsgränsen

Det finns tre vanliga sätt att placera en dokumentförhandsgranskning i en produkt. Det rätta valet beror på vem som äger navigation, autentisering och visar‑livscykel.

Mönster	Bästa passform	Huvudsaklig avvägning
Applikationsvy	En .NET-sida som renderar visaren bredvid produktkontroller	Tät integration, men sidan och visarens livscykel är kopplade
Applikationsägd iframe	En portal som behöver isolering mellan värd‑UI och förhandsgranskningsrutt	Tydlig gräns, men kommunikationen måste designas explicit
Ramverkskomponent runt en serverrutt	Ett React-, Angular- eller Vue‑skal som stöds av en .NET‑applikation	Bekant front‑end‑komposition, med fler livscykel‑tillstånd att hantera

Iframemönstret behöver inte peka på en offentlig dokument‑URL. Det kan peka på en autentiserad rutt i din egen applikation. Den rutten kan verifiera åtkomst och rendera visarsidan utan att exponera en lagringsväg för värdsidan.

Bygg en stabil, responsiv förhandsgranskningsyta

Rekonstruera inte visarmarkup eller initiering från ett illustrativt bloggsnutt. Doconut publicerar filerna, middleware‑stegen, namnrymderna och visarinställningarna som är lämpliga för varje stödd .NET‑linje. Till exempel förklarar den officiella .NET 6 eller högre installationsguiden server‑middleware, visarobjekt, dokumentalternativ, renderingskonfiguration och nödvändiga klient‑tillgångar.

Använd dessa versionsstyrda material för att skapa visaren, och ge sedan dess värdregion en stabil bredd och höjd i din egen layout. Reservera tillräckligt med utrymme innan laddning så att den omgivande sidan inte hoppar, och testa verktygsfältet och första sidan vid de faktiska brytpunkterna som stöds av din produkt.

Innan du bestämmer dig för en komposition, jämför den med de officiella Doconut live‑demoerna. Demoerna täcker flera .NET‑ och front‑end‑integrationsstilar, inklusive ett dedikerat iframe‑exempel, och hjälper dig att skilja en officiellt stödd väg från en plausibel kodsnutt.

Behåll åtkomstbeslut på servern

Värdsidan bör aldrig bestämma om en användare får visa ett dokument. Innan förhandsgranskningsrutten renderas bör applikationen:

Autentisera begäran.
Auktorisera användaren för det begärda dokumentet och hyresgästen.
Lös upp dokumentet via en serverstyrd identifierare.
Öppna det via visaren först efter att dessa kontroller har passerat.
Returnera ett generiskt 'ej hittad' eller 'förbjuden' tillstånd utan att läcka lagringsdetaljer.

En opak identifierare förbättrar URL‑hygien, men den är ingen auktorisering. Applicera samma kontroller på sid‑, miniatyr‑, sök‑, annoterings‑, export‑ och utskriftsförfrågningar som du exponerar.

Bestäm hur värden och visaren kommunicerar

En applikationsvy kan anropa sina egna komponenter direkt. En iframe kräver ett snävare kontrakt. Definiera endast de händelser som värden verkligen behöver, såsom:

Förhandsgranskning klar
Dokumentet kunde inte öppnas
Aktuell sida ändrad
Sessionen har gått ut
Användaren begärde att stänga förhandsgranskningen

Om du använder postMessage, validera både event.origin och meddelandets struktur. Acceptera inte jokertecken‑origin i produktion, och skicka aldrig autentiseringsuppgifter, lagringsplatser eller råt dokumentinnehåll via meddelanden.

Behandla webbläsarbegränsningar som djupgående försvar

En iframe är inte automatiskt isolerad. Ett sandbox‑attribut kan minska funktioner, men ett alltför strikt värde kan också bryta visarskript, nedladdningar eller same‑origin‑beteende. Börja med den minsta funktionsuppsättningen som dokumenterats för din integration och testa den med din Content Security Policy.

Granska också:

frame-ancestors eller X-Frame-Options för förhandsgranskningsrutten
frame-src för värdsidan
Same-site cookie‑beteende om iframen kräver en session
Referrer‑policy för URL:er som innehåller routningsidentifierare
Cache‑rubriker för sidor som visar känsligt material

Dessa kontroller tillhör den omgivande applikationen och infrastrukturen. En visarkomponent kan inte välja rätt policy för din hyresgäst och hotmodell.

Designa laddnings-, fel- och utgångstillstånd

En tom rektangel är inte ett användbart felmeddelande. Ge värdsidan explicita tillstånd för auktoriseringsfel, ej stödd inmatning, skadade filer, tidsgränser och utgångna sessioner. Håll formuleringen handlingskraftig utan att avslöja interna vägar eller undantagsdetaljer.

För långa dokument, bevara visarkontainern medan första sidan förbereds. Om användare kan byta dokument utan att lämna sidan, avbryt föråldrade förfrågningar och återställ den synliga titeln, sidantalet och fokus innan nästa objekt laddas.

Tillgänglighet och tangentbordsbeteende

Ge varje iframe en användbar title. Gör förhandsgranskningen åtkomlig via tangentbord, tillhandahåll ett synligt sätt att återföra fokus till värdsidan, och fånga inte fokus i anpassade överlägg. Om visaren har egna tangentbordsgenvägar, dokumentera konflikter med genvägar som används av ditt produktskal.

En tillgänglig reservlösning kan erbjuda en kontrollerad nedladdning eller en alternativ representation när dina affärsregler tillåter det. Lägg inte till en offentlig fillänk enbart som reserv.

En praktisk verifieringschecklista

Innan release, verifiera hela begäransvägen snarare än bara den initiala sidladdningen:

En auktoriserad användare kan öppna ett tillåtet dokument.
En användare från en annan hyresgäst kan inte återanvända förhandsgransknings‑URL:en.
Direkta förfrågningar till visar‑relaterade slutpunkter får samma auktoriseringskontroller.
Uppdatering, bakåtnavigering och sessionens utgång ger begripliga tillstånd.
Förhandsgranskningen förblir användbar vid stödjade viewport‑storlekar och zoomnivåer.
Webbläsarkonsolfel och misslyckade nätverksförfrågningar är synliga i övervakning.
Lagrings‑ och applikationsloggar registrerar inte hemligheter eller fullständiga dokument‑URL:er.

Slutsats

Den mest underhållbara Doconut‑inbäddningen är den med ett litet, explicit kontrakt. Låt Doconut hantera dokumentvisningsrollen som beskrivs i dess versionsstyrda dokumentation, medan din applikation äger identitet, auktorisering, routing, lagring, webbläsarpolicy och användarfeedback. När du är redo att utvärdera de paketerade exemplen lokalt, använd de officiella Doconut nedladdningsresurserna istället för att kopiera källkod från en orelaterad artikel.