الانتقال من 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 يتسبّب في حدوث مشاكل أكبر بعد الإطلاق للعديد من المطوّرين.

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

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

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

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

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

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

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

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

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

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

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

على أجهزة Android، بدلاً من استخدام معرّف العميل وسر العميل، يتم تحديد تطبيقك باستخدام مجموعة من اسم الحزمة وتجزئة شهادة التوقيع. على أجهزة iOS، يتم استخدام معرّف الحزمة ومعرّف متجر التطبيقات. يمكنك الاطّلاع على المستندات الرسمية حول استرداد هذه المعلومات على صفحة المساعدة الخاصة بـ Google Cloud console.

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

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

الوصول إلى YouTube API بلا إنترنت أو لفترة طويلة

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

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

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

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

عند كتابة تطبيقات Android، يمكن للمطوّرين الاستفادة من Google Play services للتعامل مع تفاصيل التفويض. توفّر "خدمات Google Play" مسار تفويض عاديًا لجميع واجهات Google API، بما في ذلك واجهات برمجة التطبيقات لمنصة 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.