اضافه کردن قابلیت مشاهده اسناد به یک برنامهٔ تجاری بیش از قرار دادن یک PDF در یک iframe است. فایلهای Office، نقشههای CAD، فایلهای ایمیل و تصاویر نیاز به قابلیتهای رندرینگ متفاوتی دارند، در حالی که برنامه همچنان باید احراز هویت، ذخیرهسازی، مجوزدهی و نگهداری را کنترل کند.
Doconut یک SDK مشاهدهکنندهٔ سند .NET است که برای جاسازی رندرینگ و تعامل اسناد در برنامههای وب طراحی شده است. به جای ارائهٔ یک دستورالعمل کد منبع تأییدنشده، این راهنما تصمیمات یکپارچهسازی که تیم شما باید بگیرد را توضیح میدهد و اجزای استاندارد .NET را که معمولاً دور SDK قرار میگیرند شناسایی میکند.
چرا یک نمایشگر جاسازیشده متفاوت از دانلود فایل است
یک نقطهٔ انتهایی دانلود، فایل اصلی را منتقل میکند و تجربهٔ مشاهده را به نرمافزاری خارج از برنامهٔ شما میسپارد. یک نمایشگر جاسازیشده کاربر را در داخل محصول شما نگه میدارد و میتواند مکان ثابتی برای ناوبری، جستجو، مرور و سایر ویژگیهای فعال فراهم کند.
ساخت لایهٔ رندرینگ توسط خودتان دشوار است زیرا هر فرمت قوانین خاص خود را دارد:
- فایلهای PDF میتوانند شامل فونتهای جاسازیشده، حاشیهنویسیها، فرمها و مجموعههای صفحهٔ بسیار بزرگ باشند.
- فایلهای Word، Excel و PowerPoint نیاز به چیدمان دقیق و مدیریت فونت دارند.
- نقشههای CAD به مقیاسگذاری دقیق، لایهها و زوم جزئیات نیاز دارند.
- فرمتهای ایمیل و تصویر پیوستها، متادیتا، رنگ و نگرانیهای وضوح را معرفی میکنند.
یک SDK اختصاصی به تیم برنامه اجازه میدهد تا بر کنترل دسترسی، جریانهای کاری و تجربهٔ کاربری تمرکز کند به جای نگهداری یک رندرر جداگانه برای هر فرمت پشتیبانیشده.
گام ۱: تأیید فرمتها و ویژگیهای مورد نیاز
با یک فهرست واقعی از فایلهایی که کاربران شما باز میکنند، شروع کنید. فرمتهای اساسی را از فرمتهای گاهبهگاه جدا کنید و نمونههای نمایندهای برای تست ثبت کنید.
چکلیست شما ممکن است شامل موارد زیر باشد:
- اسناد PDF و XPS
- اسناد پردازش متن
- صفحات گسترده
- ارائهها
- نقشههای CAD
- فایلهای ایمیل
- فرمتهای تصویر رایج
سپس ویژگیهایی که برای هر جریان کاری مهم هستند شناسایی کنید. مشاهده، جستجوی متن، حاشیهنویسی، چاپ و تبدیل قابلیتهای متفاوتی هستند و ممکن است به مؤلفهها یا مجوزهای متفاوت Doconut نیاز داشته باشند.
قبل از تعهد به یک فرمت یا ویژگی، صفحهٔ [صفحهٔ نمایشگر Doconut] (https://doconut.com/en/products/viewer) را مرور کنید. قابلیتهای محصول میتوانند تغییر کنند، بنابراین تستهای پذیرش شما باید مرجع نهایی برای اسنادی باشد که مشتریان شما واقعاً استفاده میکنند.
گام ۲: انتخاب منبع ورود اسناد به برنامه
یک برنامهٔ ASP.NET میتواند اسناد را از چند منبع کنترلشده دریافت کند:
- بارگذاریای که به عنوان
IFormFileدر ASP.NET Core مدیریت میشود - مکان فایل محافظتشده
- یک مخزن مدیریت اسناد یا پایگاهداده
- ذخیرهسازی شیء که توسط سرور دسترسی دارد
- سرویس داخلی که یک
Streamبرمیگرداند
جریان مشاهده باید از یک مرجع سند با مجوز سرور استفاده کند. اعتبارهای ذخیرهسازی، مسیرهای فایل بدون محدودیت یا URLهای عمومی دائمی را در نشانهگذاری سمتکلاینت قرار ندهید.
اگر کاربران فایلها را بارگذاری میکنند، قبل از رندرینگ آنها را اعتبارسنجی کنید. اندازهٔ فایل، پسوند، امضای فایل و هر محدودیت خاص کسبوکار را بررسی کنید. شناسهٔ تولید‑شده توسط سرور را ذخیره کنید نه اینکه به نام فایل اصلی به عنوان مسیر اعتماد کنید.
گام ۳: تعریف احراز هویت و مجوزدهی
برنامه—نه رابط کاربری نمایشگر—باید تصمیم بگیرد چه کسی مجاز به باز کردن یک سند است.
در ASP.NET Core، مکانیزمهای استاندارد مانند میدلویر احراز هویت، ویژگی [Authorize]، سیاستها، ادعاها و مجوزدهی مبتنی بر منبع میتوانند نقطهٔ انتهایی که یک جلسهٔ مشاهده را آغاز میکند محافظت کنند. تصمیم مجوزدهی باید هم کاربر فعلی و هم سند درخواستشده را در بر بگیرد.
یک جریان درخواست امن به این شکل است:
- کاربر با استفاده از یک شناسهٔ سطح برنامه درخواست یک سند میکند.
- سرور کاربر را احراز هویت میکند.
- سرور تأیید میکند که کاربر میتواند به آن سند خاص دسترسی داشته باشد.
- سرور مکان ذخیرهسازی محافظتشده را حل میکند.
- نمایشگر فقط اطلاعات لازم برای آن جلسهٔ دارای مجوز را دریافت میکند.
هرگز فرض نکنید مخفی کردن یک دکمهٔ نوار ابزار، کنترل مجوزدهی است. بررسیهای دسترسی سمت سرور حتی زمانی که کنترلهای دانلود یا چاپ نشان داده نمیشوند، همچنان ضروری هستند.
گام ۴: افزودن Doconut از طریق منابع یکپارچهسازی رسمی آن
از بستهٔ فعلی و دستورالعملهای راهاندازی ارائهشده توسط Doconut استفاده کنید. صفحهٔ [صفحهٔ دانلود Doconut] (https://doconut.com/en/download) دسترسی به منابع یکپارچهسازی NuGet، مستندات، مثالها و دمویها را فراهم میکند.
راهاندازی دقیق میتواند به موارد زیر وابسته باشد:
- نوع برنامهٔ ASP.NET یا .NET شما
- محصول و افزونههای انتخابی Doconut
- نسخهٔ Doconut
- مجوز شما
- فرمتها و ویژگیهای سندی که فعال میکنید
- پیکربندی سرور ویندوز شما
مستنداتی را دنبال کنید که با نسخهٔ نصبشده مطابقت دارد. از کپی کردن قطعات اولیه از پستهای بلاگ نامرتبط خودداری کنید زیرا فضاینامها، پیکربندی، مسیرهای دارایی و APIها بین نسخهها ممکن است تغییر کنند.
گام ۵: ایجاد یک مرز مشاهدهٔ اختصاصی
مشاهدهٔ سند را پشت یک سرویس کوچک برنامه نگه دارید به جای فراخوانی عملکردهای SDK در سراسر کنترلرها و مؤلفههای UI.
این سرویس میتواند مسئول موارد زیر باشد:
- حل یک شناسهٔ سند دارای مجوز
- باز کردن سند بهعنوان یک
Streamکنترلشده در زمان مناسب - فراهم کردن پیکربندی مورد نیاز برای مشاهده
- آزادسازی منابع فایل و استریم
- ترجمهٔ خطاهای فنی به خطاهای ایمن برنامه
- ثبت معیارهای عملیاتی بدون لاگکردن محتوای سند
این مرز ارتقاءها را آسانتر میکند و خطر افشای جزئیات ذخیرهسازی به لایهٔ ارائه را کاهش میدهد. همچنین به تستها یک مکان واضح برای جایگزینی یک پیادهسازی ایمن میدهد.
گام ۶: طراحی صفحهٔ نمایشگر
نمایشگر باید فضای کافی برای کاربردی بودن داشته باشد. یک کارت باریک احاطهشده توسط کنترلهای نامرتبط، بررسی صفحات گستردهٔ بزرگ و نقشههای CAD را دشوار میکند.
صفحه را بر پایهٔ موارد زیر برنامهریزی کنید:
- ارتفاع ثابت نمایشگر
- حالتهای واضح بارگذاری، خالی و خطا
- عنوان سند مختصر
- کنترلهای اطراف قابل دسترسی با صفحهکلید
- چیدمانی که کنترلهای مهم نمایشگر را مخفی نکند
- روشی صریح برای بازگشت به جریان کاری والد
با نامهای طولانی فایل، تعداد صفحات زیاد، صفحات گستردهٔ عریض، نقشههای دقیق و اسنادی که رندر نمیشوند تست کنید. حالت خطا نباید مسیرهای سرور، ردگیری استثنا یا URLهای ذخیرهسازی را فاش کند.
گام ۷: مدیریت فایلها و دادههای موقت
قبل از استقرار، یک سیاست نگهداری تعریف کنید. فایل اصلی، دادههای رندرینگ موقت، کشها، خروجیها، حاشیهنویسیها و لاگها را جداگانه در نظر بگیرید.
اقدامات حفاظتی مفید شامل موارد زیر هستند:
- یک پوشهٔ موقت اختصاصی با دسترسیهای محدود
- نامهای منحصر بهفرد تولید‑شده توسط سرور
- پاکسازی پس از جلسات موفق یا ناموفق
- فرآیند زمانبندیشده برای فایلهای موقت رهاشده
- سهمیههای ذخیرهسازی و نظارت
- رمزنگاری در حالت استراحت در صورتی که سیاست امنیتی شما اینرا میطلبد
پاکسازی را قابل مشاهده کنید. اگر حذف بهصورت ساکن شکست بخورد، فایلهای موقت میتوانند انباشته شوند و هم مشکل عملیاتی و هم امنیتی ایجاد کنند.
گام ۸: پیکربندی محافظهای تولیدی
رندرینگ اسناد میتواند CPU، حافظه و فضای دیسک موقت را مصرف کند. برنامه را با محدودیتهای صریح محافظت کنید:
- حداکثر اندازهٔ بارگذاری
- حداکثر تعداد کارهای رندرینگ همزمان
- زمانسنجی درخواست و پردازش
- محدودیت صفها هنگام رندرینگ بهصورت ناهمزمان
- سهمیههای ذخیرهسازی موقت
- بررسیهای سلامت و مانیتورینگ خطاهای ساختاری
برای بارهای کاری بزرگ یا غیرقابل پیشبینی، رندرینگ را از فرآیندهای حساس به تأخیر برنامه جدا کنید. با اسناد شبیه به مشتریان واقعی اندازهگیری کنید نه فقط با فایلهای تست کوچک.
گام ۹: تست کامل جریان کاری
یک تست یکپارچهسازی موفق باید بیش از «صفحهٔ اول ظاهر شد» را پوشش دهد.
تست کنید:
- هر فرمت فایل مورد نیاز
- فایلهای کوچک، بزرگ، چندصفحهای و خراب
- اسنادی با فونتهای غیرمعمول
- فایلهای رمزگذاریشده وقتی جریان کاری شما از آنها پشتیبانی میکند
- کاربران دارای مجوز و بدون مجوز
- جلسات مشاهدهٔ همزمان
- راهاندازی مجدد برنامه و درخواستهای قطعشده
- پاکسازی پس از موفقیت و شکست
- ویژگیهای نمایشگر شامل در پیکربندی محصول انتخابی شما
یک مجموعهٔ نسخهبندیشده از اسناد تستی تمیز نگه دارید. هنگام ارتقاء Doconut، .NET، Windows Server، زیرساخت ذخیرهسازی یا وابستگیهای مرتبط، آن را دوباره اجرا کنید.
فهرست بررسی امنیتی
قبل از انتشار، اطمینان حاصل کنید که:
- هر درخواست مشاهده نیاز به احراز هویت مناسب دارد.
- برای سند خاص، مجوزدهی بررسی میشود.
- ورودیهای تحت کنترل کاربر نمیتوانند به مسیر فایل سرور بدون محدودیت تبدیل شوند.
- اعتبارهای ذخیرهسازی هرگز به کلاینت نمیرسند.
- محدودیتها و اعتبارسنجی بارگذاری فعال هستند.
- فایلهای موقت دسترسی محدود دارند و سیاست پاکسازی تستشدهای دارند.
- لاگها محتوای سند، رازها و URLهای حساس را شامل نمیشوند.
- پیامهای خطا نشان دادهشده به کاربران پاکسازی شدهاند.
- کنترلهای SDK و برنامه از یک فرآیند بهروزرسانی پیروی میکنند.
کنترلهای نمایشگر میتوانند به جریان کاری کسبوکار شما کمک کنند، اما نمیتوانند هر شکل از ضبط را پس از مشاهده اطلاعات توسط کاربر مجاز جلوگیری کنند. از آنها همراه با کنترلهای دسترسی و سیاست حفاظت مناسب اطلاعات استفاده کنید.
جایگاه Doconut
Doconut قابلیت مشاهدهٔ سند را داخل برنامهٔ .NET شما فراهم میکند، در حالی که برنامهٔ شما مسئول هویت، مجوزدهی، ذخیرهسازی فایل، نگهداری، حسابرسی و جریان کاری پیرامون آن میماند.
این تقسیم مسئولیتها مسیر عملی برای تیمهای .NET فراهم میکند تا اسناد تجاری را بدون ساخت چندین موتور رندرینگ از ابتدا پشتیبانی کنند. همچنین جزئیات یکپارچهسازی مخصوص محصول را به مستندات رسمی نسخهای که استقرار میدهید مرتبط میسازد.
[SDK نمایشگر سند .NET Doconut] (https://doconut.com/en/products/viewer) را بررسی کنید، سپس از [منابع رسمی دانلود و مستندات] (https://doconut.com/en/download) برای ارزیابی آن با اسناد خود استفاده کنید.
نتیجهگیری
یک نمایشگر سند جاسازیشدهٔ قابل اعتماد با نیازهای واضح فرمت و یک جریان سند امن در سمت سرور شروع میشود. ورودیها را اعتبارسنجی کنید، هر درخواست سند را مجوزدهی کنید، دسترسی به SDK را پشت یک سرویس برنامه ایزوله کنید، پاکسازی فایلهای موقت را برنامهریزی کنید و با فایلهای واقعی تست کنید.
با این پایهها، Doconut میتواند لایهٔ نمایش را برای برنامهٔ وب .NET مبتنی بر ویندوز شما فراهم کند در حالی که تیم شما کنترل معماری برنامه و چرخهٔ حیات سند را حفظ میکند.