مطالبات الأذونات هي الآلية الرئيسية للويب لحماية الإمكانات القوية التي قد تمثل خطرًا على خصوصية المستخدمين وأمانهم. من خلال طلبات الحصول على الأذونات، تهدف المتصفحات إلى التأكد من أنّ المستخدم يريد السماح للموقع الإلكتروني الذي يطلب الوصول بالوصول إلى الإمكانات المعنية. يتم استخدام طلبات الأذونات لعدد من واجهات برمجة التطبيقات، بما في ذلك التقاط الوسائط (الكاميرا والميكروفون) والموقع الجغرافي والوصول إلى مساحة التخزين وMIDI والإشعارات (يمكنك الاطّلاع على وثائق Permissions API في MDN للحصول على مزيد من المعلومات).
يوضّح هذا الدليل أفضل الممارسات لعرض طلبات الحصول على الأذونات للمستخدمين استنادًا إلى إحصاءات استخدام Chrome والأبحاث في سلوكيات المستخدمين. عند اتّباع أفضل الممارسات هذه، من المفترض أن يواجه المستخدمون عددًا أقل من الطلبات غير الضرورية، ما يؤدي إلى اتّخاذ المطوّرين قرارات أقل بشأن "الحظر". تنتهي المقالة ببعض أنماط الرموز البرمجية للعمل باستخدام واجهات برمجة التطبيقات المحظورة على الأذونات، بالإضافة إلى أفضل الممارسات لمساعدة المستخدمين على استرداد حالة الحظر.
أفضل الممارسات المتعلّقة بالطلب
يجب طلب الإذن بعد تفاعل المستخدم، أي في اللحظة التي يتمكن فيها المستخدمون من فهم سبب سؤالك والفائدة التي سيحصلون عليها من السماح. حيثما أمكن، يجب أن تسمح للمستخدمين باستخدام وسائل بديلة لإنجاز نفس الوظيفة. كإرشاد عام، فإن طلب الإذن أقل تكرارًا عن طريق اختيار اللحظات التي تسأل فيها بعناية يقلل من احتمالات دخول المستخدمين إلى حالة حظر يصعب استردادها. تقدم أفضل الممارسات التالية مزيدًا من التفاصيل حول كل اقتراح من هذه الاقتراحات.
عدم السؤال مطلقًا عند تحميل الصفحة أو بدون تفاعل المستخدم
يتساوى طلب الإذن من المستخدمين عند تحميل الصفحة مع سؤال العميل عن معلومة حساسة أثناء دخوله إلى متجر فعلي. إنّ ظهور طلب للحصول على إذن (ربما من بين عدة طلبات أخرى تطلب الاشتراك في النشرات الإخبارية والموافقة على ملفات تعريف الارتباط) هو تجربة مزعجة للغاية. لن يفهم المستخدمون سبب طرح سؤال عليهم وكيف سيستفيدون.
حتى إذا كان تطبيق الويب الخاص بك لا يعمل بدون الوصول إلى إمكانية معينة، ينبغي أن تمنح المستخدمين فرصة لفهم سبب الحاجة إليه. على سبيل المثال، من خلال تقديم طلب للحصول على الإذن مسبقًا يشرح الحاجة ويمنح المستخدمين خيارًا (مثلاً، من خلال توفير وسائل بديلة لإنجاز الوظائف نفسها، متى أمكن ذلك)، إذا كنت لا تستطيع التفكير في وقت أفضل لطلب الإذن مقارنةً بتحميل الصفحة، فهناك بعض الأمثلة لاحقًا في هذا الدليل.
ومن الحالات السيئة الأخرى لطلب الإذن، وهو عدم اتّخاذ إجراء سابق من المستخدم (وهو ما يُعرف أيضًا باسم التفعيل العابر من المستخدم). يُظهر القياس عن بُعد في Chrome أنّ% 77 من طلبات الأذونات على Chrome لأجهزة الكمبيوتر المكتبي تظهر بدون هذه الإشارة الأساسية فقط إلى نية المستخدم بالشراء، وبالتالي يُسمح بنسبة %12 فقط من تلك الطلبات. بعد تفاعل المستخدم، يمكنك السماح بزيادة المعدّل إلى 30%. لذلك، لا تطلب الإذن إلا بعد أن يتفاعل المستخدم مع الصفحة في نموذج ما.
السؤال فقط عندما يتمكن المستخدمون من فهم سبب سؤالك
غالبًا ما تكون قرارات الأذونات عبارة عن قرارات متعلقة بالخصوصية. استنادًا إلى إطار عمل سلامة السياق، نعلم أنّ القرارات المتعلقة بالخصوصية تستند إلى سياق كبير. يمكن اعتبار فهم سبب أهمية الوصول جانبًا رئيسيًا من هذا. لذلك، يجب أن تطلب فقط الإمكانات التي تحتاج إليها لمنح المستخدمين قيمةً (والتي يُرجح أن يوافق عليها المستخدِمون بأنّهم سيستفيدون منها بالفعل). بالإضافة إلى ذلك، يجب طلب الإذن في لحظة يتضح فيها للمستخدم سبب فائدة هذه الإمكانية. الهدف هو تسهيل فهم سياق الاستخدام على المستخدمين قدر الإمكان.
وتُظهِر أبحاث المستخدمين التي نجريها أنّ المستخدمين يميلون بشكل كبير إلى السماح لهم بالوصول إلى المحتوى عندما يفهمون سبب طلب الموقع الإلكتروني الحصول على إذن بالوصول إلى الموقع الإلكتروني مع إدراكهم لميزة معيّنة. نلاحظ أيضًا أنّ المستخدمين يتوقّعون استكشاف المواقع الإلكترونية غير المألوفة أولاً لفهم القيمة التي يمكنهم الحصول عليها مقابل السماح بالوصول إلى تلك المواقع. وغالبًا ما يرفض أو يتجاهل مطالبات الأذونات في غضون ذلك. وباستخدام أذونات لمرة واحدة، قد تسمح بزيارة واحدة أولاً. يحتاج تطبيقك إلى دعم هذه السلوكيات.
توفير وسائل بديلة لتحقيق نفس الوظائف حيثما أمكن
قد لا تكون نتيجة بعض الإمكانات مفيدة للمستخدمين. على سبيل المثال، قد يؤدي تحديد الموقع الجغرافي لجهاز كمبيوتر مكتبي بدون أداة استشعار لنظام تحديد المواقع العالمي (GPS) إلى عرض الموقع الجغرافي غير الصحيح لأنّ هذا الشخص متصل بشبكة VPN. قد لا يريد المستخدمون الآخرون منح إمكانية الوصول إلى الحافظة لأنّهم يفضّلون مواصلة التحكّم في هذه الأحداث وتشغيلها باستخدام مجموعات المفاتيح يدويًا. في مثل هذه المواقف، من المهم توفير وسيلة بديلة لتحقيق نفس النتائج. على سبيل المثال، في حال طلب إذن رصد الموقع الجغرافي، قدِّم حقلاً نصيًا يمكن للمستخدمين من خلاله إدخال رمز بريدي أو عنوان بأنفسهم. باستخدام الحافظة، تأكد من أنه يمكن أيضًا تحديد العناصر المراد نسخها ونسخها من خلال مجموعة مفاتيح أو قائمة السياق. مع الإشعارات، يمكنك أن تعرض على الأشخاص استلام رسائل إلكترونية بدلاً من الإشعارات الفورية.
هناك نمط مفيد وهو استخدام واجهة المستخدم البديلة أيضًا كشرح لسبب أن الوصول قد يكون مفيدًا. سيشعر المستخدمون الذين يرون خيارًا لإدخال موقع بجانب الزر الذي يشغّل واجهة برمجة تطبيقات الموقع الجغرافي وبالمثل، إذا كان هناك خيار بين تلقي الإشعارات من خلال الدفع التلقائي أو البريد الإلكتروني، أو الانضمام إلى اجتماع دون السماح بالوصول إلى الكاميرا والميكروفون، يفهم المستخدمون بشكل طبيعي المفاضلات التي يجرونها.
لا تضع نفسك في حالة الحظر، فمن الصعب التعافي من
وبعد أن يقرِّر المستخدم عدم السماح نهائيًا بالوصول إلى إمكانية الوصول إلى إذن الوصول إلى البيانات، تطبّق المتصفحات هذا القرار. إذا كان من الممكن الاستمرار في المطالبة بالوصول، فستستمر المواقع سيئة المعنى في مضايقة المستخدمين بالطلبات. لذلك، يحتاج المستخدم عمدًا إلى استرداد بعض الجهد، للتعافي من الحالة المحظورة. وبالتالي، تجنَّب طلب الإذن من المستخدمين في الحالات التي يُحتمل ألا يسمح العديد من المستخدمين بالوصول إليها.
تتمثل إحدى الطرق الشائعة لإجراء ذلك في استخدام ما يُعرف بطلب مسبق، حيث تشرح للمستخدمين ما هم على وشك الحدوث ولماذا يحتاج تطبيقك إلى الميزة التي ستطلبها. ولا يجب تشغيل طلب الحصول على إذن المتصفّح إلا عندما يتفاعل المستخدمون بالإيجاب مع هذا الطلب المسبق. هناك مواقف قد يحتاج فيها المستخدمون بشكل مشروع إلى استعادة تلك الحالة. يمكنك الاطّلاع على القسم مساعدة المستخدمين في استرداد حالة الحظر لمعرفة مزيد من المعلومات حول هذا الموضوع.
الانتباه إلى المحتوى التابع لجهات خارجية
هناك مصدر غير متوقّع لطلبات الحصول على أذونات يجب أن تكون على دراية بها. في حال تضمين نصوص برمجية تابعة لجهات خارجية على موقعك الإلكتروني، قد تؤدي إلى ظهور طلبات الحصول على أذونات لم تكن تنوي عرضها. ويمكن أن يؤثر ذلك في تجربة المستخدمين على موقعك الإلكتروني، خاصةً إذا كانت هذه الطلبات لا تتبع أفضل الممارسات التي سبق أن تم توضيحها. للتحكم في تجارب المستخدمين، يجب عليك قراءة وثائق أي مكتبات ونصوص برمجية تابعة لجهات خارجية تضيفها إلى التعليمات البرمجية الخاصة بك.
متى تطلب الإذن
في ما يلي بعض الأمثلة على اللحظات التي تنجح في طلب الإذن، من خلال اتّباع أفضل الممارسات التي سبق أن تم توضيحها:
- بعد أن ينقر المستخدم على الزر "استخدام موقعي الجغرافي" بجانب حقل النموذج لإدخال العنوان يدويًا.
- بعد أن اشترك أحد المستخدمين في قناة فيديو أو مشاركات، ونقر على زر تأكيدي في مربّع حوار يصفه بإمكانية تسليم التحديثات في شكل رسائل إلكترونية أو إشعارات إلى هاتفه أو جهاز كمبيوتر سطح المكتب.
- بعد أن يصل المستخدم إلى صفحة تجهّزه للانضمام إلى مكالمة فيديو وأجاب بالإيجاب عن رغبته في أن يتم عرض هذا المستخدم والاستماع إليه من خلال طلب مسبق (راجِع دراسة الحالة من Google Meet).
أنماط الرموز البرمجية لطلب الإذن
يتم الحصول على الإذن لاستخدام واجهة برمجة التطبيقات من خلال وسائل مختلفة، بناءً على واجهة برمجة التطبيقات. تستخدم بعض واجهات برمجة التطبيقات (القديمة عادةً) نموذجًا يطلب فيه المتصفّح تلقائيًا الإذن في المرة الأولى التي تحاول فيها استخدام واجهة برمجة التطبيقات. أحد الأمثلة على ذلك هو
Geolocation API عند طلب
navigator.geolocation.getCurrentPosition().
try {
navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
console.error(error);
}
وتستخدم واجهات برمجة التطبيقات الأخرى نموذجًا تحتاج فيه صراحةً إلى طلب الإذن أولاً باستخدام طريقة ثابتة. وخير مثال على ذلك هو
Notification.requestPermission()
للسماح بالإشعارات، أو
DeviceOrientationEvent.requestPermission() الأقل شيوعًا،
والتي تُعدّ جزءًا من واجهة برمجة تطبيقات أحداث توجيه الجهاز. وتجدر الإشارة إلى أنّ بعض المتصفّحات قد تمنح
الإذن تلقائيًا لواجهات برمجة تطبيقات معيّنة. على سبيل المثال، يسمح Chrome دائمًا بالوصول إلى اتجاه الجهاز، بينما يعرض Safari طلبًا.
const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
/* Use the API. */
}
كيفية التحقّق من حالة الأذونات
لمعرفة ما إذا كان بإمكانك استخدام واجهة برمجة تطبيقات معيّنة، استخدِم الطريقة navigator.permissions.query() من Permissions API.
const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
// Use the API.
}
مساعدة المستخدمين على استعادة حالة الحظر
لمساعدة المستخدمين في تحديد مشاكل الوصول وحلّها، عليك اكتشاف أنّهم حظروا الوصول باستخدام واجهة برمجة التطبيقات Permissions API وتقديم دليل لهم حول كيفية تغيير إعداداتهم. على سبيل المثال، عندما يتفاعل المستخدمون مع عناصر واجهة المستخدم المرتبطة بإمكانية مغلقة بالأذونات، استخدِم النمط الموضّح في القسم السابق وافتح مربّع حوار لتحديد المشاكل وحلّها. تختلف الخطوات الدقيقة لتغيير حالة الإذن حسب المتصفّح، لذا ننصحك بتقديم أوصاف مطابقة استنادًا إلى سلسلة وكيل المستخدم وللمتصفّحات الأكثر استخدامًا في منتجك.
في متصفّح Chrome، يجب أن ينتقل المستخدمون إلى عناصر التحكم في الموقع الإلكتروني بالنقر على الرمز "ضبط" على الجانب الأيمن من شريط العناوين. هنا، يمكنهم تشغيل الإذن المناسب. وفي بعض الحالات، قد يحتاج المستخدمون إلى إعادة تحميل الصفحة قبل استخدام هذه الإمكانية. في هذه الحالة، سيظهر شريط رسائل أعلى النافذة يعرض عليك إعادة التحميل عند النقر على الزر المعنيّ.
وتتوفّر في المتصفّحات الأخرى واجهات مستخدم مشابهة للتحكم في الأذونات (على سبيل المثال، يمكنك الاطّلاع على آلية عمل ذلك في Firefox).