این راهنما نحوه رعایت رایج‌ترین مسائل توسعه‌دهنده را که هنگام آماده‌سازی برنامه برای تولید با آن‌ها مواجه می‌شوید، شرح می‌دهد.
نمای کلی
وقتی آماده بودید راه‌حل پیاده‌سازی‌شده‌تان را فراتر از محیط توسعه نرم‌افزار برای کاربران برنامه‌تان مستقر کنید، ممکن است لازم باشد مراحل دیگری را برای رعایت خط‌مشی‌های OAuth 2.0 در Google انجام دهید. در این راهنما، نحوه رعایت کردن رایج‌ترین مشکلات توسعه‌دهنده را که هنگام آماده‌سازی برنامه برای تولید با آن‌ها مواجه می‌شوید، شرح می‌دهیم. این کار به شما کمک می‌کند تا با کمترین خطا به بیشترین مخاطب ممکن دسترسی پیدا کنید.
- استفاده از پروژه‌های جداگانه برای آزمایش و تولید
- فهرستی از مخاطبین مرتبط با پروژه را حفظ کنید
- هویتتان را به‌طور دقیق نشان دهید
- فقط حوزه‌هایی را که نیاز دارید درخواست کنید
- ارسال برنامه‌های تولیدی که از دامنه‌های غیرحساس یا غیرمحدود برای درستی‌سنجی استفاده می‌کنند
- فقط از دامنه‌هایی که مالک آن‌ها هستید استفاده کنید
- میزبانی صفحه اصلی برای برنامه‌های تولید
- استفاده از URIهای هدایت امن و مبدأهای جاوا اسکریپت
از پروژه‌های جداگانه برای آزمایش و تولید استفاده کنید
خط‌مشی‌های OAuth در Google به پروژه‌های جداگانه‌ای برای آزمایش و تولید نیاز دارند. برخی‌از خط‌مشی‌ها و الزامات فقط برای برنامه‌های تولید اعمال می‌شود. ممکن است لازم باشد پروژه جداگانه‌ای ایجاد و پیکربندی کنید که شامل کارخواه‌های OAuth مربوط به نسخه تولید برنامه شما باشد که برای همه «حساب‌های Google» دردسترس است.
کارخواه‌های Google OAuth که در محیط تولید استفاده می‌شوند، نسبت‌به کارخواه‌های OAuth مشابهی که همان برنامه را آزمایش یا اشکال‌زدایی می‌کنند، به ارائه محیطی پایدارتر، قابل‌پیش‌بینی‌تر، و امن‌تر برای جمع‌آوری و ذخیره داده‌ها کمک می‌کنند. پروژه تولید شما می‌تواند برای درستی‌سنجی ارسال شود و بنابراین مشمول الزامات تکمیلی برای دامنه‌های خاص API شود که ممکن است شامل ارزیابی‌های امنیتی شخص ثالث باشد.
- به کنسول Google API بروید. روی ایجاد پروژه کلیک کنید، نامی وارد کنید، و روی ایجاد کلیک کنید.
- کارخواه‌های OAuth را در این پروژه که ممکن است با ردیف آزمایشی شما مرتبط باشند مرور کنید. درصورت لزوم، کارخواه‌های OAuth مشابهی برای کارخواه‌های تولید در پروژه تولیدتان ایجاد کنید.
- هر میانای برنامه‌سازی کاربردی‌ای را که مشتریانتان استفاده می‌کنند فعال کنید.
- پیکربندی «صفحه کسب رضایت OAuth» را برای پروژه جدید در صفحه نمانام‌سازی «کنسول Cloud» مرور کنید.
کارخواه‌های Google OAuth که در تولید استفاده می‌شوند نباید حاوی محیط‌های آزمایشی، URIهای هدایت، یا مبدأهای جاوا اسکریپت باشند که فقط برای شما یا تیم توسعه‌تان دردسترس است. در زیر چند نمونه آورده شده است:
- سرورهای آزمایشی توسعه‌دهندگان فردی
- نسخه‌های آزمایشی یا پیش‌انتشار برنامه‌تان
فهرستی از مخاطبین مرتبط با پروژه را حفظ کنید
Google و میاناهای برنامه‌سازی کاربردی تکی که فعال می‌کنید ممکن است لازم باشد درباره تغییرات سرویس‌هایشان یا پیکربندی‌های جدیدی که برای پروژه شما و مشتریانش لازم است با شما تماس بگیرند. فهرست‌های IAM پروژه‌تان را مرور کنید تا مطمئن شوید افراد مربوطه در تیمتان به ویرایش یا مشاهده پیکربندی پروژه‌تان دسترسی دارند. این حساب‌ها ممکن است ایمیل‌هایی درباره تغییرات الزامی در پروژه‌تان نیز دریافت کنند.
نقش شامل مجموعه‌ای از اجازه‌ها است که به شما امکان می‌دهد کنش‌های خاصی را روی منابع پروژه انجام دهید. ویرایشگران پروژه برای کنش‌هایی که وضعیت را تغییر می‌دهند، مثل توانایی ایجاد تغییرات در صفحه رضایت OAuth پروژه شما، اجازه دارند. مالکان پروژه که همه اجازه‌های ویرایشگر را دارند می‌توانند حساب‌های منسوب به پروژه را اضافه یا حذف کنند، یا پروژه را حذف کنند. مالکان پروژه همچنین می‌توانند زمینه‌ای برای اینکه چرا اطلاعات صورت‌حساب ممکن است تنظیم شود، ارائه دهند. مالکان پروژه می‌توانند اطلاعات صورت‌حساب را برای پروژه‌ای که از میاناهای برنامه‌سازی کاربردی پولی استفاده می‌کند راه‌اندازی کنند.
مالکان و ویرایشگران پروژه باید به‌روز نگه داشته شوند. می‌توانید چندین حساب مرتبط به پروژه‌تان اضافه کنید تا مطمئن شوید دسترسی به پروژه و نگهداری مربوطه ادامه می‌یابد. وقتی اعلان‌هایی درباره پروژه‌تان یا به‌روزرسانی‌هایی برای سرویس‌هایمان وجود داشته باشد، به آن حساب‌ها ایمیل ارسال می‌کنیم. سرپرستان سازمان Google Cloud باید مطمئن شوند که هر پروژه در سازمانشان با یک مخاطب دردسترس مرتبط است. اگر اطلاعات تماس به‌روز برای پروژه‌تان نداشته باشیم، ممکن است پیام‌های مهمی را که نیاز به اقدام شما دارند ازدست بدهید.
هویتتان را به‌طور دقیق نشان دهید
نام برنامه معتبر و درصورت تمایل، نشان‌واره‌ای برای نمایش به کاربران ارائه دهید. این اطلاعات نمانام باید به‌طور دقیق نشان‌دهنده هویت برنامه شما باشد. اطلاعات نمانام‌سازی برنامه ازطریق صفحه نمانام‌سازی OAuth پیکربندی می‌شود.
برای برنامه‌های تولید، اطلاعات نمانام تعریف‌شده در صفحه رضایت OAuth شما باید به‌تأیید برسد تا به کاربران نمایش داده شود. کاربران ممکن است پس‌از تکمیل درستی‌سنجی نمانام برنامه شما، احتمال بیشتری داشته باشد که به آن دسترسی اعطا کنند. اطلاعات پایه برنامه، که شامل نام برنامه، صفحه اصلی، شرایط خدمات، و خط‌مشی رازداری است، در صفحه اعطای دسترسی، هنگام مرور دسترسی‌های موجود، یا به سرپرستان Google Workspace که استفاده از برنامه را توسط سازمانشان مرور می‌کنند، نشان داده می‌شود.
Google می‌تواند دسترسی به «سرویس‌های Google API» و دیگر محصولات و سرویس‌های Google را برای برنامه‌هایی که هویتشان را به‌اشتباه معرفی می‌کنند یا سعی می‌کنند کاربران را فریب دهند لغو یا تعلیق کند.
فقط حوزه‌هایی را که نیاز دارید درخواست کنید
درطول توسعه برنامه‌تان، ممکن است از یک گستره نمونه ارائه‌شده توسط میانای برنامه‌سازی کاربردی برای ایجاد اثبات مفهوم در برنامه‌تان استفاده کرده باشید تا درباره ویژگی‌ها و عملکرد میانای برنامه‌سازی کاربردی بیشتر بدانید. این دامنه‌های نمونه اغلب اطلاعات بیشتری نسبت‌به آنچه پیاده‌سازی نهایی برنامه‌تان نیاز دارد درخواست می‌کنند، زیرا پوشش جامعی از همه کنش‌های ممکن برای یک میانای برنامه‌سازی کاربردی خاص ارائه می‌دهند. برای مثال، گستره نمونه ممکن است اجازه‌های خواندن، نوشتن، و حذف را درخواست کند، درحالی‌که برنامه شما فقط به اجازه‌های خواندن نیاز دارد. اجازه‌های مربوط را درخواست کنید که محدود به اطلاعات مهم لازم برای اجرای برنامه‌تان باشد.
اسناد مرجع را برای نقاط پایانی میانای برنامه‌سازی کاربردی که برنامه‌تان فراخوانی می‌کند مرور کنید و گستره‌هایی را که برای دسترسی به داده‌های مربوطه موردنیاز برنامه‌تان لازم است یادداشت کنید. هرگونه راهنمای مجوزی را که API ارائه می‌دهد مرور کنید و گستره آن‌ها را با جزئیات بیشتر شرح دهید تا رایج‌ترین موارد استفاده را دربرگیرد. حداقل دسترسی به داده را که برنامه شما برای فعال کردن ویژگی‌های مرتبط نیاز دارد انتخاب کنید.
برای اطلاعات بیشتر درباره این الزام، بخش فقط گستره‌هایی را درخواست کنید که به آن‌ها نیاز دارید در «خط‌مشی‌های OAuth 2.0» را به‌همراه بخش درخواست اجازه‌های مربوطه در «خط‌مشی داده‌های کاربر سرویس‌های Google API» بخوانید.
برنامه‌های تولیدی را که از دامنه‌های غیرحساس یا غیرمحدود استفاده می‌کنند برای درستی‌سنجی ارسال کنید
«ورود به سیستم با Google» درحین اصالت‌سنجی کاربر، دامنه‌های حساس و محدودشده را درخواست نمی‌کند. اگر برنامه‌تان از «ورود به سیستم با Google» فقط برای اصالت‌سنجی استفاده می‌کند، باید برنامه‌تان را برای درستی‌سنجی نمانام ارسال کنید. می‌توانید ازطریق صفحه نمانام‌سازی در «کنسول Google Cloud» برای درستی‌سنجی ارسال کنید. این درستی‌سنجی برای نمایش عناصر نمانام‌سازی برنامه (ازجمله نام، نشان‌واره، خط‌مشی رازداری، شرایط خدمات، و دامنه‌ها) در «صفحه رضایت» ضروری است.
اکیداً توصیه می‌کنیم برنامه‌تان از رهنمودهای نمانام‌سازی رسمی برای قرار دادن دکمه «ورود به سیستم» پیروی کند.
فقط از دامنه‌هایی که مالک آن‌ها هستید استفاده کنید
فرایند درستی‌سنجی صفحه رضایت OAuth در Google مستلزم درستی‌سنجی همه دامنه‌های مرتبط با صفحه اصلی، خط‌مشی رازداری، شرایط خدمات، URIهای هدایت مجاز، یا مبدأهای جاوا اسکریپت مجاز پروژه شما است. فهرست دامنه‌هایی را که برنامه‌تان استفاده می‌کند و در بخش دامنه‌های مجاز ویرایشگر صفحه رضایت OAuth خلاصه شده است مرور کنید و دامنه‌هایی را که مالک آن‌ها نیستید و بنابراین نمی‌توانید درستی‌سنجی کنید شناسایی کنید. برای درستی‌سنجی مالکیت دامنه‌های مجاز پروژه‌تان، از کنسول جستجوی Google استفاده کنید. از «حساب Google» مرتبط با پروژه «کنسول API» خود به‌عنوان «مالک» یا «ویرایشگر» استفاده کنید.
اگر پروژه شما از ارائه‌دهنده خدماتی با دامنه مشترک و همگانی استفاده می‌کند، توصیه می‌کنیم پیکربندی‌هایی را فعال کنید که امکان استفاده از دامنه خودتان را فراهم می‌کند. برخی‌از ارائه‌دهندگان پیشنهاد می‌دهند که سرویس‌هایشان را به زیردامنه‌ای از دامنه‌ای که ازقبل دارید نگاشت کنند.
میزبانی صفحه اصلی برای برنامه‌های تولید
هر برنامه تولیدی که از OAuth 2.0 استفاده می‌کند باید صفحه اصلی‌ای داشته باشد که به‌صورت عمومی دردسترس باشد. کاربران بالقوه برنامه‌تان ممکن است برای کسب اطلاعات بیشتر درباره ویژگی‌ها و عملکردهایی که برنامه ارائه می‌دهد، از صفحه اصلی بازدید کنند. کاربران فعلی ممکن است فهرست دسترسی‌های اعطاشده فعلی‌شان را مرور کنند و برای یادآوری استفاده مداوم از پیشنهاد شما، از صفحه اصلی برنامه‌تان بازدید کنند.
صفحه اصلی برنامه‌تان باید شامل شرحی از عملکرد برنامه و همچنین پیوندهایی به خط‌مشی رازداری و شرایط خدمات اختیاری باشد. صفحه اصلی باید در دامنه تأییدشده‌ای باشد که تحت مالکیت شما است.
از URIهای هدایت و مبدأهای جاوا اسکریپت امن استفاده کنید
کارخواه‌های OAuth 2.0 برای برنامه‌های وب باید داده‌هایشان را بااستفاده از شناسه منبع یکسان تغییرمسیر اچ‌تی‌تی‌پی‌اس و مبدأهای جاوا اسکریپت ایمن کنند، نه اچ‌تی‌تی‌پی ساده. Google می‌تواند درخواست‌های OAuth را که از بافت ایمن منشأ نمی‌گیرند یا به آن منتهی نمی‌شوند رد کند.
درنظر بگیرید که کدام برنامه‌ها و اسکریپت‌های طرف سوم ممکن است به کدهای امنیتی و دیگر اطلاعات کاربری کاربر که به صفحه‌تان برمی‌گردند دسترسی داشته باشند. دسترسی به داده‌های حساس را با مکان‌های URI هدایت که به درستی‌سنجی و ذخیره داده‌های کد محدود شده‌اند محدود کنید.
مراحل بعدی
پس‌از اینکه مطمئن شدید برنامه‌تان با خط‌مشی‌های OAuth 2.0 در این صفحه مطابقت دارد، برای جزئیات مربوط به فرایند درستی‌سنجی، به ارسال برای درستی‌سنجی نمانام مراجعه کنید.