Przeglądarka Doconut to biblioteka .NET do przeglądania dokumentów, zaprojektowana do osadzania plików PDF, Office, CAD, obrazów i innych obsługiwanych rodzin dokumentów w aplikacji. Solidna integracja Doconut polega mniej na znalezieniu najkrótszego fragmentu kodu, a bardziej na wybraniu czystej granicy między Twoją aplikacją, przeglądarką a przeglądarką dokumentów.

Podgląd osadzonego dokumentu rozmieszczony w uporządkowanym środowisku aplikacji internetowej

Centrum dokumentacji Centrum dokumentacji Doconut zawiera odnośniki do utrzymywanych ścieżek konfiguracji dla obsługiwanych typów projektów .NET. Użyj przewodnika odpowiadającego wersji zainstalowanej w Twojej aplikacji, a następnie traktuj otaczającą stronę, kontrole tożsamości i przepływ dostępu jako kod aplikacji, którego właścicielem jest Twój zespół.

Rozpocznij od granicy integracji

Istnieją trzy typowe sposoby umieszczenia podglądu dokumentu w produkcie. Odpowiedni wybór zależy od tego, kto zarządza nawigacją, uwierzytelnianiem i cyklem życia przeglądarki.

Wzorzec	Najlepsze dopasowanie	Główna kompromis
Widok aplikacji	Strona .NET renderująca przeglądarkę obok kontrolek produktu	Ścisła integracja, ale cykl życia strony i przeglądarki są powiązane
Iframe zarządzany przez aplikację	Portal wymagający izolacji między interfejsem hosta a trasą podglądu	Jasna granica, ale komunikacja musi być zaprojektowana explicite
Komponent frameworka wokół trasy serwera	Powłoka React, Angular lub Vue wspierana aplikacją .NET	Znane komponowanie front‑endowe, z większą liczbą stanów cyklu życia do zarządzania

Wzorzec iframe nie musi wskazywać na publiczny adres URL dokumentu. Może wskazywać na uwierzytelnioną trasę w Twojej własnej aplikacji. Ta trasa może weryfikować dostęp i renderować stronę przeglądarki bez ujawniania ścieżki przechowywania stronie hosta.

Zbuduj stabilną, responsywną powierzchnię podglądu

Nie odtwarzaj kodu HTML przeglądarki ani inicjalizacji na podstawie przykładowego fragmentu bloga. Doconut publikuje pliki, kroki middleware, przestrzenie nazw i konfigurację przeglądarki odpowiednie dla każdej obsługiwanej wersji .NET. Na przykład oficjalny przewodnik konfiguracji .NET 6 lub wyższego wyjaśnia middleware serwera, obiekt przeglądarki, opcje dokumentu, konfigurację renderowania oraz wymagane zasoby klienckie.

Użyj tych wersjonowanych materiałów do stworzenia przeglądarki, a następnie nadaj jej regionowi hostującemu stałą szerokość i wysokość w własnym układzie. Zarezerwuj wystarczającą przestrzeń przed załadowaniem, aby otaczająca strona nie przeskakiwała, i przetestuj pasek narzędzi oraz pierwszą stronę przy rzeczywistych punktach przerwania obsługiwanych przez Twój produkt.

Zanim zdecydujesz się na kompozycję, porównaj ją z oficjalnymi demo na żywo Doconut. Demo obejmują różne style integracji .NET i front‑endu, w tym dedykowany przykład iframe, i pomagają odróżnić oficjalnie wspieraną ścieżkę od pozornie poprawnego fragmentu kodu.

Trzymaj decyzje o dostępie po stronie serwera

Strona hosta nigdy nie powinna decydować, czy użytkownik może wyświetlić dokument. Przed renderowaniem trasy podglądu aplikacja powinna:

Uwierzytelnić żądanie.
Autoryzować użytkownika do żądanego dokumentu i najemcy.
Rozwiązać dokument przy użyciu identyfikatora kontrolowanego przez serwer.
Otworzyć go w przeglądarce dopiero po pomyślnym przejściu tych kontroli.
Zwrócić ogólny stan nieznaleziono lub zabroniony, nie ujawniając szczegółów przechowywania.

Nieprzezroczysty identyfikator poprawia higienę URL, ale nie jest autoryzacją. Zastosuj te same kontrole do żądań strony, miniatury, wyszukiwania, adnotacji, eksportu i drukowania, które udostępniasz.

Zdecyduj, jak host i przeglądarka komunikują się

Widok aplikacji może wywoływać własne komponenty bezpośrednio. Iframe wymaga węższego kontraktu. Zdefiniuj tylko zdarzenia, których host naprawdę potrzebuje, takie jak:

Podgląd gotowy
Nie udało się otworzyć dokumentu
Zmieniono bieżącą stronę
Sesja wygasła
Użytkownik poprosił o zamknięcie podglądu

Jeśli używasz postMessage, zweryfikuj zarówno event.origin, jak i strukturę wiadomości. Nie akceptuj wildcardowych originów w produkcji i nigdy nie przekazuj poświadczeń, lokalizacji przechowywania ani surowej zawartości dokumentu w wiadomościach.

Traktuj ograniczenia przeglądarki jako warstwową obronę

Iframe nie jest automatycznie izolowany. Atrybut sandbox może ograniczyć możliwości, ale zbyt restrykcyjna wartość może również zepsuć skrypty przeglądarki, pobieranie lub zachowanie same‑origin. Zacznij od najmniejszego zestawu możliwości udokumentowanego dla Twojej integracji i przetestuj go z Twoją polityką Content Security Policy.

Dodatkowo sprawdź:

frame-ancestors lub X-Frame-Options dla trasy podglądu
frame-src dla strony hosta
Zachowanie ciasteczek same-site, jeśli iframe wymaga sesji
Politykę referera dla URL‑i zawierających identyfikatory routingu
Nagłówki cache dla stron wyświetlających wrażliwe materiały

Te kontrole należą do otaczającej aplikacji i infrastruktury. Komponent przeglądarki nie może wybrać właściwej polityki dla Twojego najemcy i modelu zagrożeń.

Zaprojektuj stany ładowania, błędów i wygaśnięcia

Pustokątny prostokąt nie jest przydatnym komunikatem o błędzie. Dostarcz stronie hosta wyraźne stany dla niepowodzenia autoryzacji, nieobsługiwanego wejścia, uszkodzonych plików, przekroczenia limitu czasu i wygasłych sesji. Utrzymuj sformułowania w formie działań, nie ujawniając wewnętrznych ścieżek ani szczegółów wyjątków.

W przypadku długich dokumentów zachowaj kontener przeglądarki, gdy przygotowywana jest pierwsza strona. Jeśli użytkownicy mogą przełączać dokumenty bez opuszczania strony, anuluj przestarzałe żądania i zresetuj widoczny tytuł, liczbę stron oraz fokus przed załadowaniem kolejnego elementu.

Dostępność i zachowanie klawiatury

Nadaj każdemu iframe przydatny atrybut title. Umożliw podgląd dostępny za pomocą klawiatury, zapewnij widzialny sposób powrotu fokusu do strony hosta i nie blokuj fokusu wewnątrz własnych nakładek. Jeśli przeglądarka ma własne skróty klawiaturowe, udokumentuj konflikty ze skrótami używanymi w powłoce Twojego produktu.

Dostępna alternatywa może oferować kontrolowane pobranie lub alternatywną reprezentację, gdy pozwalają na to zasady biznesowe. Nie dodawaj publicznego linku do pliku wyłącznie jako alternatywy.

Praktyczna lista kontrolna weryfikacji

Przed wydaniem zweryfikuj pełną ścieżkę żądania, a nie tylko początkowe załadowanie strony:

Autoryzowany użytkownik może otworzyć dozwolony dokument.
Użytkownik z innego najemcy nie może ponownie użyć adresu URL podglądu.
Bezpośrednie żądania do endpointów związanych z przeglądarką otrzymują te same kontrole autoryzacji.
Odświeżenie, nawigacja wstecz i wygaśnięcie sesji generują zrozumiałe stany.
Podgląd pozostaje użyteczny przy obsługiwanych rozmiarach widoku i poziomach powiększenia.
Błędy w konsoli przeglądarki i nieudane żądania sieciowe są widoczne w monitoringu.
Logi przechowywania i aplikacji nie zapisują sekretów ani pełnych adresów URL dokumentów.

Zakończenie

Najbardziej utrzymywalne osadzenie Doconut to takie z małym, wyraźnym kontraktem. Pozwól Doconut obsłużyć rolę przeglądania dokumentów opisaną w jego wersjonowanej dokumentacji, podczas gdy Twoja aplikacja zarządza tożsamością, autoryzacją, routingiem, retencją, polityką przeglądarki i informacjami zwrotnymi dla użytkownika. Gdy będziesz gotowy ocenić gotowe przykłady lokalnie, użyj oficjalnych zasobów pobierania Doconut zamiast kopiowania kodu ze niepowiązanego artykułu.