الأذونات الدائمة لواجهة برمجة التطبيقات File System Access API

Thomas Steiner

هناك الآن طريقة للحصول على إذن وصول مستمر للقراءة والكتابة إلى الملفات والمجلدات بدون الحاجة إلى منح الأذونات بشكل متكرر. تشرح هذه المشاركة طريقة عملها. قبل التعمق في التفاصيل، ملخص سريع للوضع الراهن والمشكلة التي يتم حلها.

التحديات المتعلقة بالطريقة الحالية

تسمح واجهة برمجة التطبيقات File System Access API للمطوّرين بالوصول إلى الملفات على القرص الثابت المحلي للمستخدم بطريقة قراءة و(اختياريًا) في الكتابة. ومن بين التطبيقات الرائجة (من بين تطبيقات كثيرة أخرى) يستفيد من واجهة برمجة التطبيقات هذه هو Visual Studio Code (VS Code)، وهو IDE من Microsoft يتم تشغيله مباشرةً في المتصفح. عندما تفتح VS Code، يتم الترحيب بك بشاشة الترحيب حيث يمكنك إنشاء ملف جديد أو فتح ملف أو مجلد موجود.

إذا نقرت على فتح المجلد واخترت أحد المجلدات الموجودة على القرص الثابت، سيسألك المتصفح عما إذا كنت تريد أن يحصل رمز VS على إذن لعرض هذا المجلد.

بعد منح إذن الوصول، يمكنك التنقّل في التسلسل الهرمي للمجلدات وفتح الملفات في محرِّر VS Code. إذا أجريت تعديلاً على أي من الملفات، سيسألك المتصفح عما إذا كنت تريد منح إذن التعديل بالوصول إلى المجلد.

فإذا سمحت بذلك، يتغير رمز الملف في شريط العناوين، وتتم إضافة سهم صغير للأسفل للإشارة إلى أنّ التطبيق لديه أذونات للقراءة والكتابة. لتغيير الأذونات، انقر على الرمز ثم على إزالة إمكانية الوصول، بحيث لا يمكن للتطبيق تعديل الملفات بعد ذلك.

تستمر إمكانية الوصول إلى أن يتم إغلاق علامة التبويب الأخيرة من المصدر. إذا أغلقت التطبيق بعد ذلك وفتحته مرة أخرى، سيتيح لك رمز VS Code نوعًا المتابعة من حيث توقفت. عند النقر على فتح مؤخرًا، يعرض رمز VS المجلد الذي تم فتحه في وقت سابق لإعادة فتحه.

ولكن حتى إذا سبق لك منْح إذن الكتابة للمجلد، عليك الآن منح الإذن بالوصول مرة أخرى. هذا يتعب بسرعة حقًا. قبل البدء في الحل، أي الأذونات المستمرة لواجهة File System Access API، كيف تتمكن VS Code من تذكر المجلدات الحديثة؟

في File System Access API، تتم إدارة الوصول إلى الملفات والمجلدات من خلال عناصر FileSystemHandle: FileSystemFileHandle كائنات للملفات وكائنات FileSystemDirectoryHandle للمجلدات (الأدلة). ويمكن تخزين كلاهما في IndexedDB، وهذا بالضبط ما تفعله VS Code. يمكنك معرفة ذلك من خلال فتح "أدوات مطوري البرامج في Chrome" والانتقال من علامة التبويب التطبيق إلى قسم "قاعدة البيانات المفهرَسة" واختيار الجدول ذي الصلة vscode-filehandles-store في قاعدة بيانات "vscode-web-db".

الطريقة الجديدة: ما الذي يتم تغييره وموعد التغيير

يطرح Chrome سلوكًا جديدًا يتيح للمستخدمين منح إذن الوصول الدائم إلى ملفاتهم ومجلداتهم، بدون الحاجة إلى طلب الإذن من جديد باستمرار. ويمكن ملاحظة السلوك الجديد اعتبارًا من الإصدار 122 من Chrome. ولاختباره في وقت سابق، يمكنك التبديل بين العلامتَين chrome://flags/#file-system-access-persistent-permission وchrome://flags/#one-time-permission اعتبارًا من الإصدار 120 من Chrome، وذلك إلى مفعّل.

أولاً، يتكوّن السلوك الجديد من طلب جديد لإذن ثلاثي الاتجاه يتيح للمستخدمين اختياريًا منح التطبيقات الإذن بالوصول إلى ملفات ومجلدات محدَّدة عند كل زيارة.

تحتوي المطالبة الجديدة ثلاثية الاتجاهات على الخيارات التالية:

• السماح هذه المرة: يسمح هذا الإذن للتطبيق بالوصول إلى الملفات للجلسة الحالية. (يتوافق هذا مع السلوك الحالي).
• السماح في كل زيارة: يسمح هذا الإذن للتطبيق بالوصول إلى غير محدّد ما لم يتم إبطال الوصول. بمجرد منح التطبيق إمكانية الوصول المستمر، ستتمكن أيضًا من الوصول باستمرار إلى الملفات والمجلدات التي تم فتحها حديثًا.
• عدم السماح: لا يسمح هذا الخيار للتطبيق بالوصول إلى الملفات. (هذا بما يتوافق مع السلوك الحالي).

ثانيًا، يستلزم السلوك الجديد قسمًا جديدًا في إعدادات الموقع الإلكتروني، يمكن للمستخدمين الوصول إليه من خلال رمز الإطلاق بجانب مفتاح تبديل تعديل الملفات.

عند النقر على رمز التشغيل هذا، يتم فتح إعدادات الخصوصية والأمان للتطبيق المعنيّ حيث تظهر للمستخدم قائمة بالعناصر لجميع الملفات والمجلدات التي يمكن للتطبيق الوصول إليها. يمكن إبطال إمكانية الوصول لكل عنصر من خلال النقر على رمز سلة المهملات. تعني إزالة إمكانية الوصول لكل عنصر أنه لا يزال من الممكن منح التطبيق إذن الوصول إلى الملفات بشكل عام. لإبطال إذن الوصول بشكل عام، يمكن للمستخدم النقر على الرمز في شريط العناوين، كما هو موضَّح سابقًا.

كيفية تفعيل السلوك الجديد

ما من تغييرات موجّهة للمطوّرين على 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 هي إحدى الميزات الأكثر طلبًا في واجهة برمجة التطبيقات، وشهد الخطأ في التنفيذ رواجًا كبيرًا أيضًا، وقد ميّزها العديد من المطوّرين. من خلال إتاحة هذه الميزة للمطورين، وقبل كل شيء، تم إغلاق فجوة مهمة في الميزات مقارنةً بالتطبيقات الخاصة بنظام التشغيل.

خدمات الإقرار

تمّت مراجعة هذه المشاركة من قِبل كريستين هولينغزورث وأوستن سوليفان وراشيل أندرو.