طلب الأذونات وإلغاءها

تتوفر لدى كل نوع من أنواع دفق تسجيل الدخول طريقته الخاصة في طلب الأذونات، اعتمادًا على منصتك وكيفية اختيار دمج تسجيل الدخول فيسبوك:

الويب

• تستخدم مجموعة Facebook SDK للغة JavaScript خيار scope مع استدعاء الوظيفة FB.login.
• يستخدم زر تسجيل الدخول المعلمة scope أو data-scope في العنصر fb:login-button.
• يجب أن يضيف دفق تسجيل الدخول الذي تم إنشاؤه يدويًا المعلمة scope إلى عنوان URL مربع الحوار تسجيل الدخول الذي تتم إعادة التوجيه إليه.

تطبيقات الهواتف المحمولة

• بإمكان تسجيل دخول Android استخدام عدد من الفئات المختلفة لطلب الأذونات وإدارتها. يُرجى مراجعة العرض التوضيحي لتسجيل الدخول في نظام Android لمزيد من المعلومات.
• بإمكان تسجيل دخول iOS استخدام عدد من الأساليب مختلفة لطلب الأذونات. يُرجى مراجعة العرض التوضيحي لتسجيل الدخول في نظام iOS لمزيد من المعلومات.
• يستخدم Windows Phoneالمعلمة scope عند بدء استخدام اقتران URI.

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

تحسين طلبات الأذونات

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

الإرشادات

فيما يلي بعض الإرشادات التي يجب اتباعها عند طلب الأذونات، أثناء تسجيل الدخول وبعده:

• لا تطلب إلا الأذونات الضرورية للتطبيق.

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

• افصل طلب أذونات القراءة والنشر. لمزيد من التفاصيل، راجع أدناه.

• لا تطلب أبدًا الأذونات التي تعتقد أنك قد تحتاج إليها في المستقبل. حيث سيرتاب الأشخاص حيال الأمر ويرفضون تطبيقك.

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

نشر الأذونات

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

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

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

التحقق من الأذونات الحالية

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

بالنسبة لتطبيقات الويب، نوفر نقطة نهاية واجهة graph API لاسترداد قائمة الأذونات الممنوحة:

GET /{user-id}/permissions

يجب إجراء الاستدعاء من خلال رمز وصول المستخدم أو رمز وصول تطبيقك. وسيُرجع الاستدعاء سلسلة JSON تحتوي على أسماء الأذونات التي تم منحها للتطبيق وحالتها:

{
  "data": [
    {
      "permission": "public_profile",
      "status": "granted"
    },
    {
      "permission": "email",
      "status": "granted"
    },
    {
      "permission": "user_friends",
      "status": "declined"
    }
  ]
}

تتوفر أيضًا أساليب في مجموعات SDK لنظام iOS ونظام Android التي توفر تمثيلات مناسبة للمنصة للأذونات التي تم منحها لتطبيقك.

معالجة الأذونات المفقودة

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

أولاً، يجب أن تتمكن التطبيقات من معالجة أي أذونات تم طلبها ولكن لم يتم منحها:

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

{
  "error": {
    "message": "(#200) The user hasn't authorized the application
     to perform this action",
    "type": "OAuthException",
    "code": 200
  }
}

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

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

• إذا رفض شخص ما إذنًا لتطبيقك، فلن يسمح مربع الحوار تسجيل الدخول لتطبيقك بإعادة طلب الإذن إلا إذا قمت بإدخال auth_type=rerequest مع طلبك.

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

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

إلغاء الأذونات

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

يمكنك إلغاء إذن محدد من خلال إجراء استدعاء إلى نقطة نهاية واجهة Graph API:

DELETE /{user-id}/permissions/{permission-name}

يجب إجراء هذا الطلب باستخدام رمز وصول مستخدم أو رمز وصول تطبيق للتطبيق الحالي. وإذا نجح الطلب، فستتلقى استجابة بالقيمة true.

إلغاء تسجيل الدخول

يمكنك أيضًا السماح للأشخاص بشكل كامل بإلغاء مصادقة تطبيق ما أو إلغاء تسجيل دخول، من خلال إجراء استدعاء إلى نقطة نهاية واجهة Graph API هذه:

DELETE /{user-id}/permissions

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

دلائل المنصة