الانتقال من ClientLogin إلى OAuth 2.0

إيكاي لان، YouTube Developer Relations – June 2013

تستخدم واجهات برمجة تطبيقات YouTube OAuth 2.0 لتفويض طلبات المستخدمين. وكثيرًا ما يتسنّى لنا الاستفسار عمّا إذا كنّا سنضيف دعمًا إلى مصادقة ClientLogin أو ما شابه في واجهات برمجة تطبيقات YouTube من الآن فصاعدًا. ومع ذلك، فقد أوقفنا العمل رسميًا بـ ClientLogin اعتبارًا من 20 نيسان (أبريل) 2012، ولا ننوي إضافة هذه الآلية.

هناك العديد من الأسباب التي تجعلنا نعتقد أن إتاحة تدفّقات مختلفة لتفويض OAuth 2.0 تكون أفضل لمستخدمي YouTube من ClientLogin. وتتوافق هذه التدفقات مع حالات الاستخدام لتطبيقات سطح المكتب وتطبيقات الويب فقط وتطبيقات الجوّال الأصلية وحتى التطبيقات التي يتم تشغيلها على أجهزة مثل أجهزة التلفزيون التي لا تشتمل على آليات إدخال معقدة، وهو أمر يصعب تنفيذه باستخدام ClientLogin. إضافةً إلى ذلك، تبيّن لنا أنّ ClientLogin يسبّب المزيد من الإزعاج بعد إطلاق التطبيق للعديد من مطوّري البرامج، ويمكنك وصف بعضهم في مشاركة المدوّنة ClientLogin #FAIL.

استخدام OAuth 2.0 للنصوص البرمجية المستقلة من جانب الخادم

يستخدم العديد من مطوري البرامج ClientLogin لتفويض النصوص البرمجية لسطر الأوامر التي تعمل على الخوادم بدون متصفح. باستخدام OAuth 2.0، غالبًا ما يتم تضمين متصفّح - ويُستثنى من ذلك عند العمل على تطبيق Android الذي يستخدم Google Play Services لجلب الرموز المميزة عبر GoogleAuthUtil.

في تدفق على الويب فقط، يجب على موقع الويب الذي يريد إجراء مكالمات واجهة برمجة التطبيقات التي تمت مصادقتها بالنيابة عن المستخدم إعادة توجيه المستخدم إلى صفحة مصادقة google.com التي تشرح ما يحاول التطبيق الوصول إليه. بعد ذلك، يتلقى تطبيق الويب رمزًا مميزًا يستخدمه لإجراء طلبات البيانات من واجهة برمجة التطبيقات. ويمكن للمستخدم حينئذٍ إبطال حق الوصول إلى التطبيق في أي وقت باستخدام صفحة connected apps and sites.

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

الرمز المميز المستخدم هو سلسلة ASCII. إذا كان رمزًا مميزًا لـ offline، يكون قابلاً للنقل. وباستخدام الرمز المميز الذي تم استرداده، ستتمكن من تشغيل النص البرمجي على سطح المكتب، ثم نسخ الرمز واستخدامه على خادم بعيد بدون واجهة مستخدم تصويرية (GUI)، شريطة أن ينشئ هذا الرمز مثيلاً لعميل OAuth 2.0 باستخدام معرّف وسر العميل نفسه. بالإضافة إلى Python، فإن مكتبات عميل واجهة برمجة تطبيقات Google للغات البرمجة الأخرى تقدم أيضًا طرقًا مساعدة لإدارة الرموز المميزة، والتي يمكن مشاركتها بين البرامج وحتى استخدامها في مكتبات HTTP ذات المستوى الأقل مباشرة في رأس العميل أو كمعلمة عنوان URL.

في ما يلي بعض الأمثلة على النصوص البرمجية من جانب الخادم التي تستخدم الرموز المميزة بلا اتصال:

  • برنامج خفي يراقب دليلاً لتحميل الفيديوهات الجديدة تلقائيًا إلى YouTube
  • مهمة تُحدث قوائم التشغيل يوميًا بمحتوى جديد
  • نص برمجي يراقب بيانات الفيديو عبر YouTube Analytics API ويُعلِم مديري القناة عند وقوع أحداث معيّنة، مثل وقت المشاهدة الإجمالي الذي يتخطى الحدّ الأقصى. لاحظ أنه في هذه الحالة، يعتبر OAuth 2.0 طريقة التفويض المعتمدة الوحيدة نظرًا لأن واجهة برمجة تطبيقات Analytics لا تدعم ClientLogin.

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

معرّف العميل وأفضل ممارسات سر العميل

يمكن لأي رمز يتشارك في نفس معرّف العميل والزوج السري استخدام رموز الدخول نفسها. من الأفضل تقييد الوصول إلى معرِّف العميل وأسرار العميل على الرمز الذي يتم تشغيله على الأجهزة والأجهزة داخل مؤسستك.

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

على الأجهزة التي تعمل بنظام التشغيل Android، يتم تحديد تطبيقك باستخدام تركيبة من اسم الحزمة وتجزئة شهادة التوقيع بدلاً من استخدام معرِّف العميل وسر العميل. على أجهزة iOS، يتم استخدام رقم تعريف الحزمة ورقم تعريف متجر التطبيقات. يمكن العثور على المستندات الرسمية بشأن استرداد هذه المعلومات في صفحة المساعدة Google API Console.

لا تعمل حسابات الخدمة مع YouTube API

لا تعمل حسابات الخدمة مع طلبات البيانات من YouTube Data API لأن حسابات الخدمة تتطلب قناة YouTube مرتبطة بها، ولا يمكنك إقران قنوات جديدة أو حالية بحسابات الخدمة. إذا كنت تستخدم حساب خدمة لاستدعاء YouTube Data API، يعرض خادم واجهة برمجة التطبيقات خطأً مع ضبط نوع الخطأ على unauthorized مع ضبط السبب على youtubeSignupRequired.

إمكانية الوصول بلا إنترنت إلى واجهة برمجة تطبيقات YouTube لفترة طويلة

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

للتأكد من أن تطبيقك يتلقى رمزًا مميزًا للتحديث طويل الأمد وليس رمزًا مميزًا للدخول لفترة قصيرة، استخدم تدفق "التطبيق المثبّت" عند إنشاء معرّف عميل، وحدد Other لقيمة "نوع التطبيق المثبّت":

ويُوصى باستخدام تدفق "التطبيق المثبّت" لحالة الاستخدام هذه. إذا كنت تريد استخدام واجهة برمجة تطبيقات YouTube لفترة طويلة في تطبيق ويب، يمكنك استرداد معلمة من خلال ضبط المَعلمة access_type على offline والمَعلمة approval_prompt على force في طلب التفويض الأوّلي أو إعداد البرنامج. ستدير بعض مكتبات العملاء عملية جلب رموز الدخول المميزة وتحديثها. إذا كنت مهتمًا بكتابة رمز التفويض المخصص لك، فقد نشرنا مشاركة مدونة على مدونة Google Code يمكنك استخدامها كأساس لرمزك.

استخدام OAuth 2.0 مع الهواتف والأجهزة اللوحية والأجهزة الأخرى

عند كتابة تطبيقات Android، يمكن لمطوّري البرامج الاستفادة من Google Play services للتعامل مع تفاصيل التفويض. تقدّم "خدمات Google Play" عملية تفويض قياسية لجميع واجهات برمجة تطبيقات Google، بما في ذلك واجهات برمجة تطبيقات في منصّة YouTube. سيقدم هذا النهج تجربة مستخدم أفضل بكثير لمستخدمي تطبيق Android من مصادقة مخصصة باستخدام ClientLogin.

على أجهزة iOS، توفر Google خيارين:

  • Google+ Platform for iOS، الذي يدمج تسجيل الدخول إلى منتجات Google ويمكّن أيضًا الميزات الاجتماعية
  • gtm-oauth2 toolkit، التي تقدم تفويض UIWebView وتدير الرموز المميزة

بالنسبة إلى الأجهزة التي يُقصد بها أن تعمل كأجهزة "شاشة ثانية" أو أجهزة مثل أجهزة التلفزيون التي لا تشتمل على آليات إدخال سهلة الاستخدام، يُعد OAuth 2.0 للأجهزة هو الأسلوب المفضل. يعمل بروتوكول OAuth 2.0 للأجهزة من خلال عرض رمز فريد للمستخدم عند الحاجة إلى طلب تفويض. وفي هذه المرحلة، يُطلب من المستخدمين التصفح للوصول إلى http://google.com/device على جهاز آخر، مثل كمبيوتر محمول أو هاتف، وإدخال الرمز الفريد. يعرض التطبيق شاشة تشبه ما يلي:

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

ملخّص

يوفر تفويض OAuth 2.0 المرونة لمطوّري البرامج الذين يحتاجون إلى تفويض من YouTube. قد يجد مطورو البرامج الذين لديهم دراية بـ ClientLogin أن إعداد تطبيقاتهم لاستخدام OAuth 2.0 يتطلب المزيد من العمل للبدء، ولكن بعد النقل، فإن تطبيقات OAuth 2.0 توفر المزيد من المرونة والأمان وسهولة الاستخدام عبر العديد من الأنظمة الأساسية للمستخدمين.

إذا كانت لديك أي أسئلة إضافية حول OAuth 2.0 أو أي من الأمثلة الواردة في هذه المقالة، يُرجى عدم التردد في طرحها باستخدام العلامة youtube-api على StackOverflow.