Ikai Lan، YouTube Developer Relations – June 2013
«میاناهای برنامه‌سازی کاربردی YouTube» از OAuth 2.0 برای مجاز کردن درخواست‌های کاربر استفاده می‌کنند. اغلب از ما پرسیده می‌شود که آیا در آینده از اصالت‌سنجی ClientLogin یا چیزی مشابه در YouTube APIs پشتیبانی خواهیم کرد یا خیر. بااین‌حال، ما از ۲۰ آوریل ۲۰۱۲ رسماً ClientLogin را منسوخ کردیم و برنامه‌ای برای افزودن چنین سازوکاری نداریم.
دلایل متعددی وجود دارد که چرا معتقدیم پشتیبانی از جریان‌های مختلف مجوز OAuth 2.0 برای کاربران YouTube بهتر از ClientLogin است. این جریان‌ها از موارد استفاده برای برنامه‌های رایانه‌ای، برنامه‌های فقط وب، برنامه‌های تلفن همراه، و حتی برنامه‌هایی که در دستگاه‌هایی مثل تلویزیون اجرا می‌شوند و سازوکارهای ورودی پیچیده‌ای ندارند پشتیبانی می‌کنند، کاری که بااستفاده از ClientLogin دشوار است. همچنین متوجه شده‌ایم که ClientLogin پس‌از راه‌اندازی برای بسیاری از توسعه‌دهندگان دردسرهای بیشتری ایجاد می‌کند.
استفاده از OAuth 2.0 برای نوشتارهای مستقل سمت سرور
بسیاری از توسعه‌دهندگان از ClientLogin برای مجاز کردن اسکریپت‌های خط فرمان که در سرورهای بدون مرورگر اجرا می‌شوند استفاده می‌کنند. با OAuth 2.0، تقریباً همیشه مرورگری درگیر خواهد بود – استثنا زمانی است که روی یک برنامه Android کار می‌کنید که از Google Play Services برای واکشی کردن نشان‌ها ازطریق GoogleAuthUtil. استفاده می‌کند
در جریان فقط وب، وب‌سایتی که می‌خواهد ازطرف کاربر تماس‌های API اصالت‌سنجی‌شده برقرار کند باید کاربر را به صفحه اصالت‌سنجی google.com هدایت کند که توضیح می‌دهد برنامه می‌خواهد به چه چیزی دسترسی پیدا کند. سپس برنامه وب یک کد دریافت می‌کند که از آن برای برقراری تماس‌های API استفاده می‌کند. سپس کاربر می‌تواند هروقت خواست بااستفاده از صفحه connected apps and sites دسترسی برنامه را لغو کند.
نمونه‌های کد Python ما نشان می‌دهند که چگونه دستورگان خط فرمان می‌توانند مرورگر را راه‌اندازی کنند و از پنجره ترمینال فراخوانی‌های API انجام دهند، یک سرور محلی برای گوش دادن به کد پس‌از هدایت مجدد مجوز ایجاد کنند، و به‌طور خودکار یک کد برای فراخوانی‌های API آینده ذخیره کنند. ویدیویی از این عملکرد در زیر آمده است:
کد استفاده‌شده یک رشته ASCII است. اگر offline کد باشد، قابل‌حمل است. بااستفاده از کد بازیابی‌شده، می‌توانید اسکریپت را در رایانه خود اجرا کنید، سپس کد را در سرور راه دور بدون GUI کپی و استفاده کنید، مشروط بر اینکه کد یک کارخواه OAuth 2.0 را با همان شناسه کارخواه و رمز نمونه‌سازی کند. علاوه‌بر Python، کتابخانه‌های کارخواه Google API برای زبان‌های برنامه‌نویسی دیگر نیز روش‌های کمکی برای مدیریت نشان‌ها ارائه می‌دهند که می‌توانند بین کارخواه‌ها هم‌رسانی شوند و حتی مستقیماً در کتابخانه‌های HTTP سطح پایین‌تر در سرایند کارخواه یا به‌عنوان پارامتر نشانی وب استفاده شوند.
برخی‌از نمونه‌های دستورگانه‌های سمت سرور که از نشان‌های آفلاین استفاده می‌کنند:
- یک دیمون که دایرکتوری را برای ویدیوهای جدید نظارت می‌کند تا به‌طور خودکار در YouTube بارگذاری کند
- یک cron job که فهرست‌های پخش را روزانه با محتوای جدید به‌روز می‌کند
- یک اسکریپت که داده‌های ویدیو را ازطریق YouTube Analytics API نظارت می‌کند و وقتی رویدادهای خاصی رخ می‌دهد، مانند تجاوز زمان تماشای کل از یک حد مجاز، به مدیران کانال اطلاع می‌دهد. توجه داشته باشید که در این مورد، OAuth 2.0 تنها روش مجوزدهی پشتیبانی‌شده است زیرا Analytics API از ClientLogin پشتیبانی نمی‌کند.
بخش مربوط به رمزهای دسترسی بلندمدت جزئیات بیشتری درباره نحوه تولید رمزهای آفلاین ارائه می‌دهد که می‌توانند برای فرایندهای سمت سرور استفاده شوند.
روال‌های مطلوب شناسه کارخواه و رمز کارخواه
هر کدی که شناسه کارخواه و جفت رمز یکسانی داشته باشد می‌تواند از کد دسترسی یکسانی استفاده کند. بهتر است دسترسی به شناسه کارخواه و رمزهای کارخواه را به کدی محدود کنید که در ماشین‌ها و دستگاه‌های درون سازمانتان اجرا می‌شود.
شناسه کارخواه و رمز کارخواه را به‌عنوان بخشی از کد برنامه‌های تلفن همراه بومی خود لحاظ نکنید. همه توسعه‌دهندگانی که از دستگاه همراه احراز هویت OAuth 2.0 انجام می‌دهند باید از شناسه مشتری «برنامه نصب‌شده» استفاده کنند که برای تأیید اینکه درخواست فقط از برنامه‌ای که تیم شما منتشر کرده است می‌آید، اطلاعات بیشتری درخواست می‌کند.
در دستگاه‌های Android، به‌جای استفاده از شناسه کارخواه و رمز کارخواه، برنامه شما بااستفاده از ترکیبی از نام بسته و درهم‌ساز گواهی امضا شناسایی می‌شود. در دستگاه‌های iOS، از شناسه دسته نرم‌افزاری و شناسه فروشگاه برنامه‌ها استفاده می‌شود. اسناد رسمی مربوط به بازیابی این اطلاعات را می‌توانید در صفحه راهنمای Google Cloud console پیدا کنید.
«حساب‌های سرویس» با YouTube API کار نمی‌کنند
حساب‌های خدماتی برای تماس‌های YouTube Data API کار نمی‌کنند زیرا حساب‌های خدماتی به یک کانال YouTube منسوب نیاز دارند و شما نمی‌توانید کانال‌های جدید یا موجود را به حساب‌های خدماتی منسوب کنید. اگر از حساب سرویس برای فراخوانی YouTube Data API استفاده کنید، سرور 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 APIs، ازجمله APIs برای پلاتفرم YouTube، ارائه می‌دهد. این رویکرد تجربه کاربری بسیار بهتری نسبت‌به اصالت‌سنجی سفارشی بااستفاده از ClientLogin برای کاربران برنامه Android شما فراهم می‌کند.
در دستگاه‌های 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 بپرسید.