Вбудований перегляд документів має відчуватись частиною застосунку, а не передачею користувача до старого розширення браузера чи локально встановленої настільної програми. Для Windows‑базованих проектів ASP.NET і .NET, Doconut надає SDK переглядача документів, який може рендерити бізнес‑документи всередині вашого веб‑застосунку.

У цьому посібнику пояснюється архітектура перегляду без плагінів без представлення недокументованого коду Doconut.

Документи, що проходять через .NET сервіс рендерингу у вбудований переглядач без плагінів

Що означає «Без плагінів»

Переглядач без плагінів не вимагає від кінцевого користувача встановлювати технології, такі як ActiveX, Flash, Silverlight чи власне розширення браузера, перед відкриттям документа.

Це зменшує кілька джерел тертя:

Користувачам не потрібні дозволи на локальну інсталяцію.
ІТ‑командам не потрібно розповсюджувати та оновлювати клієнтський плагін.
Застосунок зберігає процес перегляду всередині власного інтерфейсу.
Залежності від застарілих плагінів не стають умовою відкриття файлу.

«Без плагінів» не означає «без залежностей». Сервер все одно потребує правильного SDK, середовища виконання, шрифтів, доступу до сховища, налаштувань та ліцензії. Застосунок також залишається відповідальним за автентифікацію, авторизацію, збереження та моніторинг.

Чому серверне рендеринг документів корисний

Бізнес‑документи складніші за звичайний веб‑контент. Файли Office, креслення CAD, електронні листи та зображення високої роздільної здатності вимагають обробки, орієнтованої на формат.

Серверний компонент .NET може виконувати цю обробку, тоді як веб‑застосунок представляє отриманий перегляд. Це дозволяє уникнути вимоги встановлювати оригінальне програмне забезпечення автора у кожного користувача.

Doconut створений саме для цієї ролі. У його поточній інформації про продукт вказана підтримка типів документів, включаючи PDF, документи Office, креслення CAD, файли електронної пошти та зображення. Перевірте точні формати та функції, необхідні вашому застосунку, на сторінці переглядача Doconut.

Планування робочого процесу перегляду

Безпечний запит документа зазвичай проходить такі кроки:

Користувач вибирає документ за ідентифікатором застосунку.
ASP.NET автентифікує запит.
Сервер перевіряє доступ до конкретного документа.
Застосунок визначає захищене розташування сховища.
Документ передається шару перегляду за допомогою підтримуваного методу інтеграції.
Застосунок реєструє результат і звільняє тимчасові ресурси.

Клієнт ніколи не повинен отримувати облікові дані сховища, необмежені серверні шляхи або більше інформації про документ, ніж вимагає авторизована сесія.

Використання стандартних меж безпеки ASP.NET

Сторінка перегляду повинна бути захищена так само, як будь‑який інший чутливий ресурс.

Стандартні механізми .NET можуть включати:

Middleware автентифікації
Атрибут [Authorize]
Політики та претензії авторизації
Авторизація на основі ресурсів
Впровадження залежностей для сховища та сервісів перегляду
Структуроване логування з фільтрацією чутливих даних

Авторизація має виконуватись на сервері. Приховування дії панелі інструментів або маршруту в інтерфейсі користувача не запобігає визначеному клієнту виконати прямий запит.

Тримайте доступ до SDK за межами сервісу застосунку

Уникайте розповсюдження викликів переглядача по всіх контролерах і сторінках. Виділений сервіс застосунку може:

Визначати авторизовані ідентифікатори документів
Відкривати контрольований Stream
Застосовувати налаштування для встановленої версії SDK
Звільняти файли та ресурси потоків
Перетворювати технічні помилки у безпечні помилки застосунку
Реєструвати час виконання та очищені діагностичні дані

Така межа спрощує тестування застосунку та зменшує вплив майбутніх оновлень SDK.

Використовуйте офіційні ресурси завантаження та документації Doconut для встановлення пакетів та рекомендацій щодо API конкретної версії.

Створення корисного контейнера переглядача

Контейнер переглядача, яким керує застосунок, має мати достатньо простору для реальних документів. Уникайте вузьких карток і фіксованих ширин під робочий стіл.

.viewer-workspace {
  display: grid;
  grid-template-rows: auto minmax(0, 1fr);
  width: 100%;
  min-height: 36rem;
  height: calc(100dvh - 4rem);
}

.viewer-host {
  min-width: 0;
  min-height: 0;
  overflow: hidden;
}

Це стандартний CSS для оточувальної сторінки, а не налаштування Doconut. Не використовуйте недокументовані внутрішні селектори і не вигадуйте параметри SDK.

Сторінка також повинна забезпечувати:

Чіткий стан завантаження
Безпечне повідомлення про помилку
Видимий заголовок документа
Шлях назад до батьківського робочого процесу
Доступні елементи керування застосунком
Достатньо місця для широких електронних таблиць і деталізованих креслень

Перевірка документів перед рендерингом

Якщо користувачі завантажують файли, перевірте:

Розмір файлу
Розширення та сигнатуру файлу
Підтримуваний формат
Вимоги щодо пароля або шифрування
Специфічні для бізнесу обмеження
Ім’я сховища, згенероване сервером

Не формуйте серверні шляхи безпосередньо з оригінальної назви файлу. Зберігайте безпечний ідентифікатор застосунку і визначайте його через авторизований серверний сервіс.

Підготовка Windows‑сервера

Поведінка рендерингу може залежати від середовища сервера. Переконайтеся у наступному:

Підтримувані версії Windows і .NET
Необхідні шрифти
Розташування та дозволи тимчасового сховища
Доступні ресурси CPU, пам’яті та дискового простору
Максимальний розмір документа та кількість одночасних сесій
Налаштування ліцензії
Процедури очищення

Тестуйте репрезентативні документи клієнтів у середовищі, що відповідає продуктивному.

Контрольний список безпеки та конфіденційності

Перед випуском:

Автентифікуйте запити перегляду, коли це потрібно.
Авторизуйте користувача для конкретного документа.
Тримайте шляхи сховища та облікові дані на сервері.
Обмежуйте дозволи тимчасових файлів.
Визначте політику збереження оригіналів, тимчасових даних та експортів.
Очищайте помилки, що відображаються користувачам.
Виключайте вміст документів і секрети з журналів.
Застосовуйте обмеження на завантаження та одночасність.
Підтримуйте SDK і залежності застосунку в актуальному стані.

Твердження про відповідність мають відображати повну розгорнуту систему та процеси вашої організації, а не лише один UI‑компонент.

Тестування поза «щасливим шляхом»

Ваша тестова бібліотека має включати:

Багатосторінкові PDF‑файли
Великі електронні таблиці
Детальні креслення CAD
Презентації з рідкісними шрифтами
Файли електронної пошти з вкладеннями
Великі зображення
Пошкоджені та непідтримувані файли
Неавторизовані запити
Одночасні сесії перегляду
Перервані запити та перезапуск застосунку

Переконайтеся, що помилки не розкривають серверні шляхи, стек‑трейси чи URL‑адреси сховища.

Де розташовується Doconut

Doconut постачає вбудовану можливість перегляду документів у .NET веб‑застосунку. Ваш застосунок забезпечує безпеку, сховище, робочий процес, адаптивне розташування та операційний контроль.

Таке розділення дозволяє командам замінювати застарілі робочі процеси, що залежать від плагінів, без створення враження, що обробка документів стає беззусильною чи безвідповідальною.

Ознайомтеся з перевіреним SDK переглядача документів Doconut для .NET, а потім скористайтеся офіційною сторінкою завантаження для інструкцій, що відповідають вашій обраній версії.

Висновок

Досвід перегляду документів без плагінів зменшує тертя встановлення і тримає користувачів всередині вашого застосунку. Побудуйте його на серверно‑авторизованому потоці документів, ізолюйте доступ до SDK, забезпечте просторий контейнер переглядача та тестуйте реальні файли під навантаженням, схожим на продакшн.

Для Windows‑базованих застосунків ASP.NET і .NET Doconut може забезпечити шар перегляду документів, тоді як ваша команда зберігає контроль над застосунком і життєвим циклом документів.