הוספת צפייה במסמכים לאפליקציית עסקית כוללת יותר ממיקום PDF ב‑iframe. קבצי Office, שרטוטי CAD, קבצי אימייל ותמונות דורשים יכולות רינדור שונות, בעוד שהאפליקציה עדיין צריכה לשלוט באימות, אחסון, הרשאה ושמירה.
Doconut היא ערכת פיתוח .NET לצפייה במסמכים שנועדה לשלב רינדור אינטראקציה של מסמכים באפליקציות אינטרנט. במקום להציג מתכון קוד מקור לא מאומת, מדריך זה מסביר את החלטות האינטגרציה שהצוות שלכם צריך לבצע ומזהה את רכיבי .NET הסטנדרטיים שלרוב מקיפים את ערכת הפיתוח.
מדוע צופה משולב שונה מהורדת קובץ
נקודת קצה של הורדה מעבירה את הקובץ המקורי ומשאירה את חוויית הצפייה לתוכנה מחוץ לאפליקציה שלכם. צופה משולב משאיר את המשתמש בתוך המוצר שלכם ויכול לספק מקום עקבי לניווט, חיפוש, סקירה ותכונות אחרות מופעלות.
בניית שכבת הרינדור בעצמכם קשה מכיוון שלכל פורמט יש חוקים משלו:
- קבצי PDF יכולים להכיל גופנים משובצים, הערות, טפסים וקבוצות עמודים גדולות מאוד.
- קבצי Word, Excel ו‑PowerPoint דורשים טיפול מדויק בפריסת גופנים.
- שרטוטי CAD צריכים קנה מידה מדויק, שכבות וזום מפורט.
- פורמטים של אימייל ותמונה מציגים קבצים מצורפים, מטא‑נתונים, צבעים ודרישות רזולוציה.
ערכת SDK ייעודית מאפשרת לצוות האפליקציה להתמקד בבקרת גישה, זרימות עבודה וחוויית משתמש במקום לתחזק מנוע רינדור נפרד לכל פורמט נתמך.
שלב 1: אימות הפורמטים והתכונות הדרושים
התחילו במלאי אמיתי של הקבצים שהמשתמשים שלכם פותחים. הפרידו פורמטים חיוניים מאלו המשמשים לעיתים, ורשמו דוגמאות ייצוגיות לבדיקות.
רשימת הבדיקה שלכם עשויה לכלול:
- מסמכי PDF ו‑XPS
- מסמכי עיבוד תמלילים
- גליונות אלקטרוניים
- מצגות
- שרטוטי CAD
- קבצי אימייל
- פורמטים נפוצים של תמונות
לאחר מכן זיהו את התכונות החשובות לכל זרימת עבודה. צפייה, חיפוש טקסט, הערות, הדפסה והמרה הן יכולות שונות שעשויות לדרוש רכיבי Doconut שונים או רישיון שונה.
סקור את היקף המוצר הנוכחי בעמוד דף מציג Doconut המאומת לפני שמתחייבים לפורמט או תכונה. יכולות המוצר עשויות להשתנות, ולכן בדיקות הקבלה שלכם צריכות להישאר הסמכות הסופית למסמכים שהלקוחות שלכם משתמשים בהם בפועל.
שלב 2: בחירת מקור הקבצים באפליקציה
אפליקציית ASP.NET יכולה לקבל מסמכים ממספר מקורות מבוקרים:
- העלאה המבוצעת כ‑
IFormFileב‑ASP.NET Core - מיקום קובץ מוגן
- מאגר נתונים או מערכת ניהול מסמכים
- אחסון אובייקטים הנגיש על‑ידי השרת
- שירות פנימי המחזיר
Stream
זרימת הצפייה צריכה להשתמש בהתייחסות מסמך מאושרת על‑ידי השרת. אל תציבו פרטי גישה לאחסון, נתיבי קבצים בלתי מוגבלים או כתובות URL ציבוריות קבועות במרקאפ בצד הלקוח.
אם משתמשים מעלים קבצים, יש לאמת אותם לפני הרינדור. בדקו גודל קובץ, סיומת, חתימת קובץ וכל מגבלה עסקית ספציפית. שמרו את המזהה שנוצר על‑ידי השרת במקום להסתמך על שם הקובץ המקורי כנתיב.
שלב 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 מסלול מעשי לתמוך במסמכי עסק ללא צורך לבנות מנועי רינדור מרובים מאפס. היא גם שומרת על פרטי אינטגרציה ספציפיים למוצר מקושרים לתיעוד הרשמי של הגרסה שאתם מפעילים.
חקור את ערכת פיתוח מציג מסמכי .NET של Doconut, ולאחר מכן השתמשו ב‑משאבי ההורדה והתיעוד הרשמי כדי להעריך אותו עם המסמכים שלכם.
סיכום
צופה משולב אמין מתחיל בדרישות פורמט ברורות ובזרימת מסמך מאובטחת בצד השרת. אמתו קלטים, הרשאו כל בקשת מסמך, בידדו גישה ל‑SDK מאחורי שירות אפליקציה, תכננו ניקוי קבצים זמניים ובדקו עם קבצים מציאותיים.
עם יסודות אלה במקום, Doconut יכול לספק את שכבת הצפייה לאפליקציית .NET Web שלכם, בעוד שהצוות שלכם שומר שליטה על ארכיטקטורת האפליקציה והמחזור החיים של המסמכים.