הרשאות קבועות ל-File System Access API

עכשיו יש דרך לקבל גישה קבועה לקריאה ולכתיבה בקבצים ובתיקיות, בלי צורך להעניק הרשאות שוב ושוב. במאמר הזה נסביר איך זה עובד. לפני שנכנס לפרטים, נסכם במהירות את המצב הקיים ואת הבעיה שאנחנו פותרים.

האתגרים בשיטה הנוכחית

File System Access API מאפשר למפתחים לגשת לקבצים בדיסק הקשיח המקומי של המשתמש לצורך קריאה וכתיבה (אופציונלי). אפליקציה פופולרית אחת (מבין רבות אחרות) שמשתמשת ב-API הזה היא Visual Studio Code‏ (VS Code), סביבת הפיתוח המשולבת (IDE) של Microsoft שפועלת ישירות בדפדפן. כשפותחים את VS Code, מופיעה המסך Welcome (ברוכים הבאים), שבו אפשר ליצור קובץ חדש או לפתוח קובץ או תיקייה קיימים.

מסך הפתיחה של Visual Studio Code.

אם לוחצים על Open Folder ובוחרים באחת מהתיקיות בדיסק הקשיח, הדפדפן יבקש מכם לתת ל-VS Code הרשאת צפייה בתיקייה הזו.

בקשה לגישת תצוגה מ-Visual Studio Code.

אחרי שמעניקים גישה, אפשר לנווט בהיררכיית התיקיות ולפתוח קבצים בעורך של VS Code. אם תבצעו שינוי באחד מהקבצים, הדפדפן יבקש מכם להעניק לתיקייה גישת עריכה.

בקשה לגישת עריכה ב-Visual Studio Code.

אם תאשרו את הבקשה, סמל הקובץ בסרגל הכתובות ישתנה ותתווסף חץ קטן למטה, שמציין שלאפליקציה יש הרשאות קריאה וכתיבה. כדי לשנות את ההרשאות, לוחצים על הסמל ואז על הסרת הגישה כדי שהאפליקציה לא תוכל יותר לערוך קבצים.

Visual Studio Code עם הנחיה לגבי סמל בסרגל הכתובות.

הגישה נמשכת עד שסוגרים את הכרטיסייה האחרונה של המקור. אם תסגרו את האפליקציה ותפתחו אותה שוב, תוכלו למעשה להמשיך מהמקום שבו הפסקתם. כשלוחצים על Open Recent, VS Code מציע לפתוח מחדש את התיקייה שנפתחה קודם.

Visual Studio Code מציג את הקבצים שנפתחו לאחרונה.

אבל גם אם כבר הענקתם הרשאת כתיבה לתיקייה, תצטרכו להעניק גישה שוב. זה מתיש מאוד מהר. לפני שנצלול לפתרון, כלומר הרשאות קבועות ל-File System Access API, איך VS Code מצליח לזכור את התיקיות האחרונות?

קוד Visual Studio מבקש גישת עריכה אחרי טעינת מחדש.

ב-File System Access API, הגישה לקבצים ולתיקיות מנוהלת באמצעות אובייקטים מסוג FileSystemHandle: אובייקטים מסוג FileSystemFileHandle לקבצים ואובייקטים מסוג FileSystemDirectoryHandle לתיקיות (ספריות). אפשר לשמור את שניהם ב-IndexedDB, וזה בדיוק מה ש-VS Code עושה. כדי לראות את זה, פותחים את Chrome DevTools, עוברים לכרטיסייה Application לקטע IndexedDB ובוחרים את הטבלה הרלוונטית vscode-filehandles-store במסד הנתונים vscode-web-db.

ניפוי באגים ב-Visual Studio Code באמצעות כלי הפיתוח של Chrome, שבו מוצג הקטע IndexedDB עם FileSystemHandle השמור.

הדרך החדשה: מה עומד להשתנות ומתי

אנחנו משיקים ב-Chrome התנהגות חדשה שמאפשרת למשתמשים להעניק גישה קבועה לקבצים ולתיקיות שלהם, כדי למנוע את הצורך לבקש מהם אישור מחדש כל הזמן. אפשר לראות את ההתנהגות החדשה החל מגרסה 122 של Chrome. כדי לבדוק את התכונה מוקדם יותר, החל מגרסה 120 של Chrome, משנים את המצב של שני הדגלים chrome://flags/#file-system-access-persistent-permission ו-chrome://flags/#one-time-permission ל-מופעל.

ראשית, ההתנהגות החדשה כוללת בקשה חדשה להרשאה עם שלוש אפשרויות, שמאפשרת למשתמשים להעניק לאפליקציות גישה לקבצים ולתיקיות שנבחרו בכל ביקור.

Visual Studio Code עם הודעה על הרשאות בשלושה כיוונים.

ההנחיה החדשה הזו עם שלוש האפשרויות כוללת את האפשרויות הבאות:

  • הפעם בלבד: הרשאה לאפליקציה לגשת לקבצים בסשן הנוכחי. (ההתנהגות הזו תואמת להתנהגות הקיימת).
  • לאפשר בכל ביקור: האפליקציה תקבל גישה ללא הגבלת זמן, אלא אם תבטלו את הגישה. אחרי שהאפליקציה תקבל גישה קבועה, תוכלו לגשת גם לקבצים ולתיקיות חדשים שתפתחו.
  • אין אישור: לאפליקציה אין גישה לקבצים. (האפשרות הזו תואמת להתנהגות הקיימת).

שנית, ההתנהגות החדשה כוללת קטע חדש בהגדרות האתר, שאליו המשתמשים יכולים להגיע דרך סמל ההפעלה לצד המתג עריכת קובץ.

הגדרות האתר של Visual Studio Code עם סמל עריכת קובץ.

כשלוחצים על סמל ההפעלה הזה, נפתחות ההגדרות של פרטיות ואבטחה באפליקציה הרלוונטית, שבהן המשתמש רואה רשימה של פריטים של כל הקבצים והתיקיות שיש לאפליקציה גישה אליהם. אפשר לבטל את הגישה לכל פריט בנפרד בלחיצה על סמל האשפה. אם תסירו את הגישה לכל פריט, עדיין תוכלו להעניק לאפליקציה גישה לקבצים באופן כללי. כדי לבטל את הגישה באופן כללי, המשתמש יכול ללחוץ על הסמל בסרגל הכתובות, כפי שמתואר למעלה.

הגדרות הפרטיות והאבטחה של Chrome לאתר vscode.dev.

איך מפעילים את ההתנהגות החדשה

אין שינויים ב-File System Access API שמיועדים למפתחים. כדי להפעיל את ההתנהגות החדשה עם הרשאות קבועות, יש שלוש דרכים עם תנאים מוקדמים שונים שצריך לעמוד בהם:

  1. המשתמש חייב להעניק הרשאה לקובץ או לתיקייה (או למספר קבצים או תיקיות) במהלך הביקור האחרון במקור, והאפליקציה חייבת לאחסן את אובייקטי ה-FileSystemHandle התואמים ב-IndexedDB. בביקור הבא במקור, האפליקציה צריכה לאחזר אחד מהאובייקטים FileSystemHandle השמורים ב-IndexedDB ולאחר מכן להפעיל את השיטה FileSystemHandle.requestPermission() שלו. אם התנאים המוקדמים האלה מתקיימים, תוצג ההנחיה החדשה עם שלוש האפשרויות.
  2. המקור חייב להפעיל את השיטה FileSystemHandle.requestPermission() ב-FileSystemHandle שניתנה לו גישה בעבר, אבל הגישה שלו בוטלה באופן אוטומטי כי הכרטיסייה הייתה ברקע במשך זמן מה. (ביטול ההרשאות האוטומטי פועל על סמך אותו לוגיקה שמתוארת במאמר הרשאות חד-פעמיות ב-Chrome). אם התנאים המוקדמים האלה מתקיימים, תוצג ההנחיה החדשה עם שלוש האפשרויות.
  3. המשתמש צריך להתקין את האפליקציה. אפליקציות מותקנות ימשיכו לשמור את ההרשאות באופן אוטומטי אחרי שהמשתמש יעניק גישה. במקרה כזה, ההנחיה עם שלוש האפשרויות לא תוצג, ובמקום זאת האפליקציה תקבל את ההתנהגות החדשה כברירת מחדל.

במקרה הראשון ובמקרה השני, בהודעה מפורטים כל האובייקטים מסוג FileSystemHandle שהאפליקציה הייתה להם גישה אליהם בעבר, ולא רק האובייקט שאליו מתבצעת הקריאה לשיטה requestPermission(). בהתאם לאופן שבו זה עובד בהרשאות חד-פעמיות, אם המשתמש דוחה או סוגר את ההודעה יותר משלוש פעמים, היא לא תוצג יותר, ובמקום זאת תוצג הודעת ההרשאה הרגילה.

ניסיון של ההתנהגות החדשה

אם יש לכם גרסה נתמכת של Chrome או שהגדרתם את הדגלים הנדרשים, תוכלו לבדוק את ההתנהגות החדשה ב-VS Code באינטרנט. פותחים תיקייה ומעניקים גישה, סוגרים את הכרטיסייה ופותחים אותה מחדש ולוחצים על פתיחת הפריטים האחרונים (שימו לב: טעינת מחדש מיידית לא מפעילה את ההנחיה, צריך לסגור את כל הכרטיסיות). בוחרים את התיקייה הקודמת וההנחיה החדשה תוצג. למקרה בדיקה מצומצם יותר, אפשר לעיין בהדגמה של גישה למערכת קבצים מתמידה ולבדוק את קוד המקור שלה.

מסקנות

הרשאות קבועות ל-File System Access API הן אחת מהבקשות הנפוצות ביותר ל-API, וגם באג ההטמעה פופולרי מאוד, ומפתחים רבים הוסיפו לו כוכב. עכשיו, כשהתכונה הזו זמינה למפתחים, ובעיקר למשתמשים, נסגר פער חשוב בתכונות בהשוואה לאפליקציות ספציפיות לפלטפורמה.

אימות חתימות

הפוסט הזה נבדק על ידי כריסטין הולינגוורת', אוסטין סאליבן ורייצ'ל אנדרו.