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