أفضل الممارسات المتعلقة بأذونات الويب

Marian Harbach

Thomas Steiner

طلبات الأذونات هي الآلية الرئيسية على الويب لحماية الإمكانات القوية التي قد تكون خطيرة على خصوصية المستخدمين وأمنهم. من خلال طلبات الحصول على الأذونات، تهدف المتصفحات إلى التأكد من أنّ المستخدم يريد السماح للموقع الإلكتروني الذي يطلب الوصول بالوصول إلى الإمكانات المعنية. تُستخدَم طلبات الأذونات مع عدد من واجهات برمجة التطبيقات، بما في ذلك التقاط الوسائط (الكاميرا والميكروفون) والموقع الجغرافي، والوصول إلى مساحة التخزين وMIDI والإشعارات (اطّلِع على مستندات Permissions API على MDN لمزيد من المعلومات).

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

أفضل الممارسات المتعلّقة بطلبات المساعدة

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

لا تطلب أبدًا الإذن عند تحميل الصفحة أو بدون تفاعل من المستخدم.

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

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

ومن الحالات السيئة أيضًا طلب الإذن بدون تفاعل سابق من المستخدِم (المعروف أيضًا باسم تفعيل عابر للمستخدِم). يُظهر القياس عن بُعد في Chrome أنّ% 77 من طلبات الأذونات على Chrome لأجهزة الكمبيوتر المكتبي تظهر بدون هذه الإشارة الأساسية إلى نية المستخدم بالشراء، وبالتالي يُسمح بنسبة %12 فقط من تلك الطلبات. بعد تفاعل المستخدم، اسمح بزيادة المعدّلات إلى 30%. لذلك، لا تطلب الإذن إلا بعد تفاعل المستخدم مع الصفحة في شكل ما.

لا تطرح الأسئلة إلا عندما يكون بإمكان المستخدمين فهم سبب طرحها.

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

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

توفير وسائل بديلة لتنفيذ الوظيفة نفسها كلما أمكن

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

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

لا تتسبّب في حظر حسابك، إذ يصعب استرداد الحساب بعد حظره.

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

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

الانتباه إلى المحتوى التابع لجهات خارجية

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

حالات طلب الإذن

في ما يلي بعض الأمثلة على اللحظات التي تناسب طلب الإذن، مع اتّباع أفضل الممارسات الموضّحة سابقًا:

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

أنماط الرموز البرمجية لطلب الإذن

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