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

Thomas Steiner

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

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

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

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

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

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

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

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

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

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

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

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

ההנחיה החדשה ל-3 כיוונים כוללת את האפשרויות האלה:

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

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

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

איך לאמן את ההתנהגות החדשה

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

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

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

רוצה לנסות את ההתנהגות החדשה?

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

מסקנות

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

אימות חתימות

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