הוספת צפייה במסמכים לאפליקציית עסקית כוללת יותר ממיקום קובץ PDF ב‑iframe. קבצי Office, שרטוטי CAD, קבצי דוא״ל ותמונות דורשים יכולות רינדור שונות, בעוד שהאפליקציה עדיין צריכה לשלוט באימות, אחסון, הרשאה ושמירת נתונים.
Doconut הוא SDK לצפייה במסמכי .NET שנועד לשלב רינדור אינטראקציה של מסמכים באפליקציות רשת. במקום להציג מתכון קוד מקור לא מאומת, מדריך זה מסביר את החלטות האינטגרציה שהצוות שלך צריך לבצע ומזהה את רכיבי .NET הסטנדרטיים שלרוב מקיפים את ה‑SDK.
למה צופה מוטמע שונה מהורדת קובץ
נקודת קצה של הורדה מעבירה את הקובץ המקורי ומשאירה את חוויית הצפייה לתוכנה מחוץ לאפליקציה שלך. צופה מוטמע משאיר את המשתמש בתוך המוצר שלך ויכול לספק מקום עקבי לניווט, חיפוש, סקירה ותכונות נוספות מופעלות.
בניית שכבת הרינדור בעצמך קשה מכיוון שלכל פורמט יש חוקים משלו:
- קבצי PDF יכולים להכיל גופנים מוטמעים, הערות, טפסים וקבוצות עמודים גדולות מאוד.
- קבצי Word, Excel ו‑PowerPoint דורשים טיפול קפדני בפריסת גופנים.
- שרטוטי CAD זקוקים לקנה מידה מדויק, שכבות וזום מפורט.
- פורמטים של דוא״ל ותמונות מציגים קבצים מצורפים, מטא‑נתונים, צבעים ודרישות רזולוציה.
SDK ייעודי מאפשר לצוות האפליקציה להתמקד בבקרת גישה, זרימות עבודה וחוויית משתמש במקום לתחזק מנוע רינדור נפרד לכל פורמט נתמך.
שלב 1: אימות הפורמטים והתכונות הדרושים
התחל במלאי אמיתי של הקבצים שהמשתמשים שלך פותחים. הפרד פורמטים חיוניים מאלו המשמשים לעתים רחוקות, ותעד דוגמאות מייצגות לבדיקות.
רשימת הבדיקה שלך עשויה לכלול:
- מסמכי PDF ו‑XPS
- מסמכי עיבוד תמלילים
- גיליונות אלקטרוניים
- מצגות
- שרטוטי CAD
- קבצי דוא״ל
- פורמטים נפוצים של תמונות
לאחר מכן זהה את התכונות החשובות לכל זרימת עבודה. צפייה, חיפוש טקסט, הערות, הדפסה והמרה הן יכולות שונות שעשויות לדרוש רכיבי Doconut שונים או רישיון שונה.
עיין בטווח הפונקציונליות של המוצר בעמוד ה‑Doconut Viewer המאומת לפני שאתה מתחייב לפורמט או תכונה. יכולות המוצר יכולות להשתנות, ולכן בדיקות הקבלה שלך צריכות להישאר הסמכות הסופית למסמכים שהלקוחות שלך משתמשים בהם בפועל.
שלב 2: בחירת מקורות הכנסת המסמכים לאפליקציה
אפליקציית ASP.NET יכולה לקבל מסמכים ממספר מקורות מבוקרים:
- העלאה המטופלת כ‑
IFormFileב‑ASP.NET Core - מיקום קובץ מוגן
- מסד נתונים או מאגר ניהול מסמכים
- אחסון אובייקטים הנגיש מהשרת
- שירות פנימי המחזיר
Stream
זרימת הצפייה צריכה להשתמש בהתייחסות למסמך המאושר על‑ידי השרת. אל תכניס אישורים לאחסון, נתיבי קבצים בלתי מוגבלים או כתובות URL ציבוריות קבועות לתגי‑HTML בצד הלקוח.
אם משתמשים מעלים קבצים, אמת אותם לפני הרינדור. בדוק גודל קובץ, סיומת, חתימת קובץ וכל מגבלה עסקית ספציפית. שמור את המזהה שנוצר על‑ידי השרת במקום להסתמך על שם הקובץ המקורי כנתיב.
שלב 3: הגדרת אימות והרשאה
היישום — ולא ממשק הצופה — צריך להחליט מי מורשה לפתוח מסמך.
ב‑ASP.NET Core, מנגנונים סטנדרטיים כגון middleware לאימות, התכונה [Authorize], מדיניות, תביעות והרשאה מבוססת משאב יכולים להגן על נקודת הקצה שמתחילה את סשן הצפייה. החלטת ההרשאה צריכה לכלול גם את המשתמש הנוכחי וגם את המסמך המבוקש.
זרימת בקשה מאובטחת נראית כך:
- המשתמש מבקש מסמך באמצעות מזהה ברמת האפליקציה.
- השרת מאמת את המשתמש.
- השרת מאמת שהמשתמש מורשה לגשת למסמך הספציפי הזה.
- השרת מאתר את מיקום האחסון המוגן.
- הצופה מקבל רק את המידע הדרוש לסשן המורשה הזה.
לעולם אל תניח שהסתרת כפתור סרגל כלים היא שליטה בהרשאה. בדיקות גישה בצד השרת נדרשות גם כאשר כפתורי הורדה או הדפסה אינם מוצגים.
שלב 4: הוספת Doconut דרך משאבי האינטגרציה הרשמיים שלו
השתמש בחבילה ובהוראות ההתקנה העדכניות שמסופקות על‑ידי Doconut. דף ה‑הורדה של Doconut המאומת מספק גישה למשאבי אינטגרציה של NuGet, תיעוד, דוגמאות והדגמות.
ההגדרה המדויקת יכולה להשתנות בהתאם ל‑:
- סוג האפליקציה שלך ב‑ASP.NET או .NET
- המוצר והפלאג‑אינים של Doconut שנבחרו
- גרסת Doconut
- הרישיון שלך
- פורמטי המסמכים והתכונות שאתה מפעיל
- תצורת השרת Windows שלך
עקוב אחרי התיעוד המתאים לגרסה המותקנת. הימנע מהעתקת קטעי קוד אתחול מפוסטים בלתי קשורים, מכיוון שמרחבי שמות, תצורות, נתיבי נכסים ו‑API יכולים להשתנות בין גרסאות.
שלב 5: יצירת גבול צפייה ייעודי
החזק את צפיית המסמכים מאחורי שירות אפליקציה קטן במקום לקרוא לפונקציונליות ה‑SDK ישירות מכל בקרן ו‑UI.
השירות הזה יכול להיות אחראי על:
- פתרון מזהה מסמך מורשה
- פתיחת המסמך כ‑
Streamמבוקר במידת הצורך - אספקת תצורת הצפייה הנדרשת
- שחרור משאבי קובץ ו‑Stream
- תרגום תקלות טכניות לשגיאות אפליקציה בטוחות
- רישום מדדי פעילות מבלי לתעד את תוכן המסמך
גבול זה מקל על עדכונים ומפחית את הסיכון לחשיפת פרטי האחסון לשכבת ההצגה. הוא גם מספק למבחנים מקום ברור להחלפת מימוש בטוח.
שלב 6: תכנון דף הצופה
הצופה צריך לקבל מספיק מקום כדי להיות שימושי. כרטיס צר שמוקף בבקרות בלתי קשורות מקשה על בחינת גיליונות גדולים ושרטוטי CAD.
תכנן את העמוד סביב:
- גובה צופה קבוע
- מצבי טעינה, ריק ושגיאה ברורים
- כותרת מסמך תמציתית
- בקרות נגישות דרך המקלדת סביב הצופה
- פריסה שאינה מסתירה בקרות חשובות של הצופה
- דרך מפורשת לחזור לתהליך העבודה הראשי
בדוק עם שמות קבצים ארוכים, ספירות עמודים גדולות, גיליונות רחבים, שרטוטים מפורטים ומסמכים שלא מצליחים להיטען. מצב השגיאה לא צריך לחשוף נתיבי שרת, עקבות חריגה או כתובות URL של אחסון.
שלב 7: ניהול קבצים ונתונים זמניים
הגדר מדיניות שמירה לפני הפריסה. התייחס לכל אחד מהפריטים הבאים בנפרד: קובץ המקור, נתוני רינדור זמניים, מטמונים, ייצוא, הערות ולוגים.
אמצעי הגנה מומלצים כוללים:
- ספרייה זמנית ייעודית עם הרשאות מוגבלות
- שמות ייחודיים שנוצרים על‑ידי השרת
- ניקוי לאחר סשנים שהושלמו או נכשלו
- תהליך מתוזמן לקבצים זמניים שננטשו
- מכסות אחסון וניטור
- הצפנה במנוחה לפי מדיניות האבטחה שלך
הפוך את תהליך הניקוי לשקוף. אם מחיקה נכשלת בשקט, קבצים זמניים יכולים להצטבר ולהפוך לבעיה תפעולית ואבטחתית.
שלב 8: קביעת הגנות לייצור
רינדור מסמכים יכול לצרוך משאבי CPU, זיכרון ומרחב דיסק זמני. הגן על האפליקציה עם מגבלות מפורשות:
- גודל העלאה מרבי
- מספר מקסימלי של משימות רינדור מתרחבות במקביל
- מגבלות זמן לבקשה ולעיבוד
- גבולות תור כאשר הרינדור מתבצע אסינכרונית
- מכסות אחסון זמני
- בדיקות בריאות וניטור שגיאות מובנה
עבור עומסים גדולים או בלתי צפויים, בידד את הרינדור מתהליכים רגישים לזמן תגובה של האפליקציה. מדוד עם מסמכים דמויי‑לקוח במקום להסתמך רק על קבצים קטנים לבדיקות.
שלב 9: בדיקת זרימת העבודה המלאה
מבחן אינטגרציה מוצלח צריך לכסות יותר מ‑“הדף הראשון הופיע”.
בדוק:
- כל פורמט קובץ נדרש
- קבצים קטנים, גדולים, מרובי‑עמודים ופגומים
- מסמכים עם גופנים לא נפוצים
- קבצים מוגנים בסיסמה כאשר תהליך העבודה שלך תומך בכך
- משתמשים מורשים ולא מורשים
- סשנים של צפייה מקבילים
- הפעלות מחדש של האפליקציה ובקשות שהופרעו
- ניקוי לאחר הצלחה וכשלון
- תכונות הצופה שנכללו בתצורת המוצר שבחרת
שמור על אוסף גרסאות של מסמכי בדיקה מנוקים. הרץ אותו מחדש בעת עדכון Doconut, .NET, Windows Server, תשתית האחסון או תלותיות קשורות.
רשימת בדיקות אבטחה
לפני השחרור, וודא כי:
- כל בקשת צפייה דורשת אימות במקומות המתאימים.
- נבדקת הרשאה ספציפית למסמך.
- קלט שנשלט על‑ידי המשתמש אינו יכול להפוך לנתיב קובץ שרת בלתי מוגבל.
- אישורי אחסון לעולם אינם מגיעים ללקוח.
- מגבלות והגדרות אימות העלאה מופעלות.
- לקבצים זמניים יש גישה מוגבלת ומדיניות ניקוי נבדקת.
- הלוגים אינם כוללים תוכן מסמכים, סודות או כתובות URL רגישות.
- הודעות שגיאה המוצגות למשתמשים מנוקות.
- בקרות ה‑SDK והאפליקציה מתעדכנות בתהליך עדכון מסודר.
בקרות הצופה יכולות לתמוך בתהליך העסקי שלך, אך הן אינן יכולות למנוע כל צורת לכידה ברגע שהמידע גלוי למשתמש מורשה. השתמש בהן יחד עם בקרות גישה ומדיניות הגנה על מידע מתאימה.
היכן Doconut מתמקם
Doconut מספק את יכולת הצפייה במסמכים בתוך אפליקציית .NET, בעוד שהאפליקציה שלך נשארת אחראית על זהות, הרשאה, אחסון קבצים, שמירה, ביקורת והזרימה המקיפה.
חלוקת האחריות הזו נותנת לצוותי .NET מסלול מעשי לתמוך במסמכי עסק ללא צורך בבניית מנועי רינדור מרובים מאפס. היא גם שומרת על פרטי האינטגרציה הספציפיים למוצר קשורים לתיעוד הרשמי של הגרסה שאתה מפעיל.
חקור את ה‑SDK לצפייה במסמכי .NET של Doconut, ולאחר מכן השתמש ב‑משאבי ההורדה והתיעוד הרשמי כדי להעריך אותו עם המסמכים שלך.
סיכום
צופה מסמכים מוטמע אמין מתחיל בדרישות פורמט ברורות ובזרימת מסמכים מאובטחת בצד השרת. אמת קלטים, אשר כל בקשת מסמך, בידד גישה ל‑SDK מאחורי שירות אפליקציה, תכנן ניקוי קבצים זמניים ובצע בדיקות עם קבצים מציאותיים.
עם היסודות האלה במקום, Doconut יכול לספק את שכבת הצפייה לאפליקציית ה‑.NET מבוססת Windows שלך בעוד שהצוות שלך שומר שליטה על ארכיטקטורת האפליקציה וחיי המסמך.