Jak osadzić przeglądarkę dokumentów bez wtyczek w ASP.NET
10.07.2026

Jak osadzić przeglądarkę dokumentów bez wtyczek w ASP.NET

Przewodnik krok po kroku dla inżynierów .NET, którzy muszą osadzić bezpieczną, bezwtyczkową przeglądarkę dokumentów Doconut App w projektach ASP.NET Core, MVC lub WebForms.

Możesz osadzić przeglądarkę dokumentów bez wtyczek w aplikacji ASP.NET Core, MVC lub WebForms, nie prosząc żadnego użytkownika o instalację czegokolwiek.
Przedsiębiorstwa udostępniające kontrakty, rysunki lub zasoby projektowe potrzebują przeglądarki, która respektuje korporacyjne polityki bezpieczeństwa i nigdy nie zmusza użytkowników do instalacji przestarzałych wtyczek przeglądarki. Doconut dostarcza .NET SDK przeglądarki dokumentów do przetwarzania PDF, Office, CAD, e‑mail i obrazów w przeglądarce. Nie jest to usługa hostowana, którą wywołujesz: instalujesz ją w swojej aplikacji i ona renderuje dokumenty. Ten wpis opisuje decyzje integracyjne bez polegania na kodzie przykładowym zależnym od wersji.

Jedno wyjaśnienie na początek, ponieważ dwa produkty łatwo pomylić. Doconut.app to darmowa przeglądarka internetowa — jeden plik, otwarty w karcie przeglądarki, usunięty później. Nie jest to coś, co można osadzić. To, co osadzasz, to Doconut Viewer, SDK, a wszystko poniżej dotyczy właśnie tego.

Osadzona przeglądarka dokumentów połączona z kontrolowanym backendem ASP.NET
Osadzona przeglądarka dokumentów połączona z kontrolowanym backendem ASP.NET

1. Dlaczego bezpieczeństwo i renderowanie bez wtyczek mają znaczenie dla aplikacji internetowych .NET

Nowoczesne przedsiębiorstwa traktują każdy dokument jako potencjalny wyciek danych. Gdy osadzasz przeglądarkę opartą na ActiveX, Flash lub natywnym kliencie, dziedziczysz trzy ryzyka:

RyzykoWpływ na Twoją aplikację .NETJak Doconut App to eliminuje
Zależność od wtyczkiUżytkownicy muszą zainstalować lub włączyć wtyczkę przeglądarki, co prowadzi do zgłoszeń wsparcia i problemów z zgodnością.Doconut działa w pełni w HTML5/Canvas, nie wymagając żadnych wtyczek.
Niezaszyfrowany transferPliki są przesyłane przez HTTP lub przechowywane w postaci niezaszyfrowanej, co narusza GDPR, HIPAA lub wewnętrzne polityki.SDK działa wewnątrz Twojej aplikacji, więc transport i przechowywanie pozostają pod polityką TLS i szyfrowania, którą już egzekwujesz. Doconut nie dodaje żadnego dodatkowego przeskoku.
Nie kontrolowany cykl życiaPliki mogą pozostawać na serwerze, zwiększając powierzchnię podatności na naruszenia.Zarządzanie retencją jest po Twojej stronie, ponieważ dokumenty nigdy nie opuszczają Twojego środowiska. Tymczasowe wyniki renderowania są zapisywane tam, gdzie to skonfigurujesz, i usuwane zgodnie z Twoim harmonogramem.

Architektonicznym faktem, który ma znaczenie, jest to, że SDK jest zainstalowane w Twoim własnym środowisku i nie wykonuje żadnych połączeń z serwerami Doconut. Nic nie jest do nas wysyłane, więc nie ma zewnętrznego procesora danych do dodania do mapy danych i nie ma polityki retencji dostawcy, którą trzeba by dopasować do Twojej.

2. Przygotowanie projektu .NET

Użyj pakietu, dokumentacji i przykładów odpowiadających wybranej wersji Doconut dla projektu. Oficjalna strona pobierania Doconut jest wiarygodnym punktem wyjścia.

Przed integracją potwierdź docelowy runtime .NET, zanotuj wersję pakietu, przechowuj konfigurację licencji poza kontrolą wersji i rozpocznij od reprezentatywnych dokumentów. ASP.NET Core, MVC i WebForms mają różne cykle życia aplikacji, więc ich konfiguracja nie powinna być traktowana jako identyczna.

3. Tworzenie bezpiecznego punktu końcowego przesyłania – AES‑256, SSL i automatyczne usuwanie

SDK może odczytać dokument z fizycznej ścieżki, strumienia, tablicy bajtów, bazy danych, URL, lokalizacji intranetowej lub dostawcy chmury takiego jak S3, Azure Storage, Google Cloud lub Dropbox. Nigdy nie powinien odczytywać ścieżki wybranej przez przeglądarkę. Umieść kontrolę autoryzacji pomiędzy żądaniem a dokumentem, niezależnie od źródła. Poniżej znajduje się typowy przykład takiego punktu końcowego w ASP.NET Core; te same zasady obowiązują w MVC i WebForms.

Przepływ pracy po stronie serwera

  1. Akceptuj przesłany plik – Użyj standardowego IFormFile (lub HttpPostedFile w WebForms), aby otrzymać dokument od klienta.
  2. Zaszyfruj plik przy użyciu AES‑256 – Przed zapisaniem strumienia, zaszyfruj go przy pomocy sprawdzonej biblioteki, takiej jak System.Security.Cryptography.Aes. Przechowuj zaszyfrowany blob w bezpiecznej lokalizacji (np. Azure Blob Storage z włączonym szyfrowaniem po stronie serwera lub w bucketcie S3 z SSE‑AES256).
  3. Wygeneruj krótkotrwały podpisany URL – Utwórz URL ważny przez kilka minut (np. 5 minut). URL powinien być HTTPS i zawierać token kryptograficzny, który Doconut może zweryfikować. Większość dostawców przechowywania w chmurze oferuje funkcję „pre‑signed URL”, która spełnia to wymaganie.
  4. Zwróć podpisany URL do klienta – Wyślij odpowiedź JSON zawierającą URL. Klient przekaże ten URL do przeglądarki Doconut.
  5. Zaplanuj automatyczne usuwanie – Po wygaśnięciu podpisanego URL, zadanie w tle (Hangfire, Azure Functions itp.) usuwa zaszyfrowany blob, zapewniając, że plik nie pozostaje na serwerze.

Odpowiedniki w MVC / WebForms

  • MVC – Umieść tę samą logikę w zwykłej akcji kontrolera i zwróć JsonResult.
  • WebForms – Zaimplementuj obsługę .ashx lub metodę strony, która wykonuje te same kroki: odbierz Request.Files[0], zaszyfruj, wygeneruj pre‑signed URL i zapisz odpowiedź JSON.

Jedyną różnicą jest składnia routingu; przepływ pracy związany z bezpieczeństwem pozostaje identyczny.


4. Renderowanie dokumentu przy użyciu zainstalowanego SDK

Utrzymuj dostęp do dokumentu na serwerze i wymuszaj autoryzację przed przetworzeniem pliku lub strumienia. Dokładna kolejność renderowania i inicjalizacji interfejsu UI jest zależna od wersji; kieruj się oficjalną dokumentacją dostarczoną z zainstalowaną wersją, zamiast kopiować niezweryfikowane globalne API JavaScript.

Dlaczego to działa we wszystkich odmianach .NET

  • ASP.NET Core Razor – Inicjalizacja znajduje się w tym samym widoku, który hostuje formularz przesyłania, więc istnieje tylko jedna strona do rozważenia.
  • MVC – Użyj @section Scripts, aby wstrzyknąć ten sam fragment kodu; kontroler zwraca JSON, który może przetworzyć $.ajax w MVC.
  • WebForms – Zarejestruj skrypt przy pomocy ClientScript.RegisterStartupScript po zakończeniu przesyłania, a następnie wywołaj launchViewer w ten sam sposób.

Renderowanie odbywa się na Twoim serwerze i o to właśnie chodzi: przeglądarka otrzymuje wyrenderowane strony zamiast źródłowego dokumentu, co wyjaśnia, dlaczego plik DWG lub PSD otwiera się na maszynie, która nie ma ani AutoCADa, ani Photoshopa. Dostosuj rozmiar serwera odpowiednio — zeskanowany 300‑stronicowy PDF to poważna praca, którą teraz wykonuje Twój tier.

5. Dostosowywanie przeglądarki do Twojego portalu

Przedsiębiorstwa zazwyczaj potrzebują, aby przeglądarka wyglądała jak część produktu, w którym jest osadzona, a nie jako okno do czyjejś aplikacji. Wygląd przeglądarki oraz zestaw udostępnianych kontrolek są konfigurowalne, a dostępne opcje zależą od zainstalowanej wersji.

Czerp nazwy opcji z dokumentacji dostarczonej z Twoją wersją, a nie z wpisu na blogu. Powierzchnie konfiguracji przeglądarki to dokładnie te elementy, które są zmieniane pomiędzy wydaniami, a fragment skopiowany z artykułu sprzed dwóch wersji nie zadziała i może wyglądać jak problem licencyjny.

Decyzja, którą warto podjąć przed otwarciem dokumentacji, to określenie, które kontrolki powinien widzieć każdy rol. Czy użytkownik może drukować, pobierać, czy tylko przeglądać dokument, to pytanie o uprawnienia, na które Twoja aplikacja już zna odpowiedź. Skonfiguruj przeglądarkę na podstawie tej odpowiedzi, zamiast udostępniać wszystkie kontrolki i liczyć na to, że nikt nie kliknie.

6. Wydajność i skalowalność – utrzymaj płynność doświadczenia

Osadzenie przeglądarki w portalu o dużym natężeniu ruchu rodzi dwa praktyczne problemy: czas ładowania i równoczesne renderowanie. Doconut App rozwiązuje oba od razu, ale możesz wzmocnić wydajność kilkoma trikami specyficznymi dla .NET.

KwestiaCo zrobić
Opóźnienie pierwszej stronyAutomatyczne ładowanie stron pozwala czytelnikowi zobaczyć pierwszą stronę, podczas gdy reszta jest jeszcze przygotowywana. Włącz kompresję plików statycznych (app.UseResponseCompression()) i buforuj zasoby po stronie klienta.
Powtarzalne wyświetlenia tego samego plikuCzęsto otwierany dokument może być wyrenderowany raz i serwowany z buforowanego wyniku zamiast renderować go przy każdym żądaniu. FAQ opisuje opcję .DCN dokładnie w tym celu.
Koszt renderowaniaRenderowanie to praca serwera. Obniżenie rozdzielczości obrazu tam, gdzie jakość nie jest krytyczna, jest najważniejszą dźwignią, i jest to zmiana konfiguracji, a nie kodu.
RównoczesnośćSprawdź ustawienia timeout i AutoClose przy obciążeniu oraz zapoznaj się z przykładami farmy serwerów, zanim założysz, że wystarczy jeden węzeł. Ogranicz szybkość (rate‑limit) punktu końcowego przesyłania.

Mierz na własnych dokumentach. 5‑MB PDF oparty na tekście i 5‑MB skan tego samego raportu zachowują się zupełnie inaczej, i tylko jeden z nich pojawia się w syntetycznym benchmarku.

Najważniejsze wnioski

  • Doconut Viewer jest SDK .NET bez wtyczek, które działa z ASP.NET Core, MVC i WebForms. Twoi użytkownicy nie instalują niczego.
  • Jest instalowany w Twoim własnym środowisku i nie wykonuje żadnych połączeń z serwerami Doconut, więc dokumenty pozostają w granicach, które już kontrolujesz.
  • Bezpieczeństwo transportu, szyfrowanie w spoczynku oraz retencja są do ustalenia przez Ciebie, ponieważ plik nigdy nie opuszcza Twojej infrastruktury. Doconut nie staje się procesorem w Twojej mapie danych.
  • Katalog SDK zawiera 75 rozszerzeń plików w 18 rodzinach — PDF, Office, CAD, Visio, Project, e‑mail, e‑Book i obrazy, z DICOM poprzez własną wtyczkę.
  • Renderowanie odbywa się na serwerze. To pozwala przeglądarce otworzyć plik DWG i jest także elementem, którego rozmiar trzeba uwzględnić.
  • To, które kontrolki widzi użytkownik — drukowanie, pobieranie lub tylko przewijanie — powinno zależeć od uprawnień, które Twoja aplikacja już posiada.
  • Pobieraj nazwy opcji konfiguracyjnych z dokumentacji dla zainstalowanej wersji, nigdy nie z artykułu.

Często zadawane pytania

Q1: Czy instaluję coś na serwerze?
A: Tak. Doconut Viewer jest SDK .NET, które instalujesz w swojej aplikacji — rozpocznij od strony pobierania i użyj pakietu oraz dokumentacji dla wybranej wersji. Nie ma hostowanego punktu końcowego do wywołania i nic nie jest serwowane z CDN Doconut.

Q2: Kto usuwa plik po obejrzeniu?
A: Ty. Ponieważ dokument i wszelkie tymczasowe wyniki renderowania znajdują się w Twoim środowisku, retencja jest ustawieniem w Twojej aplikacji, a nie obietnicą od dostawcy. Zdecyduj, gdzie zapisywane są pliki tymczasowe i co je usuwa, zanim przejdziesz do produkcji.

Q3: Czy użytkownicy mogą drukować dokument?
A: Drukowanie jest funkcją przeglądarki i może być przyznane lub odrzucone dla poszczególnych użytkowników. Zauważ, że kontrolowane drukowanie jest częścią samego przeglądarki — nie jest jednym z czterech licencjonowanych wtyczek, którymi są Adnotacje, Konwerter, DICOM i Wyszukiwanie.

Q4: Czy może konwertować dokument na inny format?
A: To jest wtyczka Converter, licencjonowana osobno. Przeglądanie i konwertowanie to tutaj różne produkty i warto jasno określić, którego z nich faktycznie potrzebuje przepływ pracy.


Gotowy, aby osadzić przeglądarkę dokumentów bez wtyczek w swojej aplikacji .NET? Rozpocznij od strony pobierania Doconut — licencja próbna jest darmowa. A jeśli naprawdę potrzebujesz otworzyć dziś jeden plik, Doconut.app robi to w zakładce przeglądarki i usuwa go później.