إيكاي لان، 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، يكون قابلاً للنقل. باستخدام الرمز المميّز الذي تم استرجاعه، ستتمكّن من تشغيل النص البرمجي على الكمبيوتر المكتبي، ثم نسخ الرمز واستخدامه على خادم عن بُعد بدون واجهة مستخدم رسومية، شرط أن ينشئ الرمز مثيلًا لعميل OAuth 2.0 باستخدام معرّف العميل والسرية نفسهما. بالإضافة إلى Python، توفّر مكتبات عملاء Google API للغات البرمجة الأخرى أيضًا طرقًا مساعدة لإدارة الرموز المميّزة، والتي يمكن مشاركتها بين العملاء وحتى استخدامها في مكتبات HTTP ذات المستوى الأدنى مباشرةً في عنوان العميل أو كمَعلمة لعنوان URL.
في ما يلي بعض الأمثلة على النصوص البرمجية من جهة الخادم التي تستخدِم الرموز المميّزة بلا إنترنت:
- برنامج تابع لنظام التشغيل يراقب دليلاً للفيديوهات الجديدة لتحميلها تلقائيًا إلى YouTube
- مهمة cron تعدّل قوائم التشغيل يوميًا باستخدام محتوى جديد
- رمز برمجي يراقب بيانات الفيديوهات من خلال YouTube Analytics API ويُرسِل إشعارات إلى مدراء القنوات عند حدوث أحداث معيّنة، مثل تجاوز وقت المشاهدة المجمّع حدًا معيّنًا. يُرجى العلم أنّ OAuth 2.0 هو طريقة التفويض الوحيدة المتاحة في هذه الحالة لأنّ Analytics API لا تتيح استخدام ClientLogin.
يوفّر القسم الخاص بعلامات الوصول صالحة لمدة طويلة مزيدًا من التفاصيل حول كيفية إنشاء الرموز المميّزة بلا إنترنت التي يمكن استخدامها للعمليات من جهة الخادم.
أفضل الممارسات المتعلّقة بمعرّف العميل وسر العميل
يمكن لأي رمز يتشارك مع رقم تعريف العميل نفسه وزوج المفتاح السري نفسه استخدام وحدات ترميز الوصول نفسها. من الأفضل حصر الوصول إلى معرِّف العميل وأسراره بالرمز البرمجي الذي يتم تشغيله على الأجهزة داخل مؤسستك.
لا تُدرِج معرّف العميل وسر العميل كجزء من رمز تطبيقاتك الأصلية للأجهزة الجوّالة. على جميع المطوّرين الذين يجرون مصادقة OAuth 2.0 من جهاز جوّال استخدام معرّف العميل "التطبيق المثبّت" الذي يطلب معلومات إضافية للتحقّق من أنّ الطلب وارد من تطبيق أصدره فريقك فقط.
على أجهزة Android، بدلاً من استخدام معرّف العميل وسر العميل، يتم تحديد تطبيقك باستخدام مزيج من اسم الحزمة ودالة تجزئة شهادة التوقيع. على أجهزة iOS، يتم استخدام معرّف الحزمة ورقم تعريف متجر التطبيقات. يمكن العثور على المستندات الرسمية حول استرداد هذه المعلومات في صفحة مساعدة Google API 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 يمكنك استخدامها كأساس لرمزك.
استخدام بروتوكول 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.