هنگامی که آماده استقرار راه حل پیاده سازی شده خود فراتر از محیط توسعه خود برای کاربران برنامه خود هستید، ممکن است لازم باشد اقدامات بیشتری را برای مطابقت با سیاست های OAuth 2.0 Google انجام دهید. در این راهنما، نحوه انطباق با رایجترین مشکلات توسعهدهنده را که هنگام آمادهسازی برنامه خود برای تولید با آن مواجه میشوند، توضیح میدهیم. این به شما کمک می کند تا با خطاهای محدود به بیشترین مخاطب ممکن دست پیدا کنید.
- از پروژه های جداگانه برای آزمایش و تولید استفاده کنید
- فهرستی از مخاطبین مربوطه برای پروژه را حفظ کنید
- هویت خود را به طور دقیق نشان دهید
- فقط دامنه هایی را که نیاز دارید درخواست کنید
- برنامههای تولیدی را ارسال کنید که از محدودههای حساس یا محدود برای تأیید استفاده میکنند
- فقط از دامنه های خود استفاده کنید
- یک صفحه اصلی برای برنامه های تولیدی میزبانی کنید
- از URI های هدایت مجدد ایمن و مبدا جاوا اسکریپت استفاده کنید
از پروژه های جداگانه برای آزمایش و تولید استفاده کنید
خطمشیهای Google OAuth به پروژههای جداگانه برای آزمایش و تولید نیاز دارد . برخی از خط مشی ها و الزامات فقط برای برنامه های تولیدی اعمال می شود. ممکن است لازم باشد پروژه جداگانهای ایجاد و پیکربندی کنید که شامل کلاینتهای OAuth میشود که با نسخه تولیدی برنامه شما در دسترس برای همه حسابهای Google مطابقت دارد.
کلاینتهای Google OAuth که در تولید استفاده میشوند، به ارائه یک محیط جمعآوری و ذخیرهسازی داده پایدار، قابل پیشبینی و ایمنتر نسبت به مشتریان OAuth مشابهی که همان برنامه را آزمایش یا اشکالزدایی میکنند، کمک میکنند. پروژه تولید شما میتواند برای تأیید ارسال شود و بنابراین مشمول الزامات اضافی برای حوزههای API خاص است که ممکن است شامل ارزیابیهای امنیتی شخص ثالث باشد.
- Go to the Google API Console. Click Create project, enter a name, and click Create.
- مشتریان OAuth را در این پروژه که ممکن است با سطح آزمایشی شما مرتبط باشند، مرور کنید. در صورت امکان، مشتریان OAuth مشابهی را برای مشتریان تولید داخل پروژه تولید خود ایجاد کنید.
- هر API در حال استفاده توسط مشتریان خود را فعال کنید .
- پیکربندی صفحه رضایت OAuth خود را در پروژه جدید مرور کنید.
کلاینتهای Google OAuth که در تولید استفاده میشوند نباید دارای محیطهای آزمایشی، URIهای هدایتکننده یا مبداهای جاوا اسکریپت باشند که فقط برای شما یا تیم توسعهدهی شما در دسترس است. در زیر چند نمونه آورده شده است:
- سرورهای آزمایشی توسعه دهندگان فردی
- نسخه های پیش از انتشار برنامه خود را آزمایش یا منتشر کنید
فهرستی از مخاطبین مربوطه برای پروژه را حفظ کنید
ممکن است لازم باشد Google، و APIهای فردی که فعال میکنید، درباره تغییرات سرویسهایش یا پیکربندیهای جدید مورد نیاز پروژه و مشتریانش با شما تماس بگیرند. لیست های IAM پروژه خود را مرور کنید تا مطمئن شوید افراد مرتبط در تیم شما به ویرایش یا مشاهده پیکربندی پروژه شما دسترسی دارند. این حسابها همچنین ممکن است ایمیلهایی درباره تغییرات لازم در پروژه شما دریافت کنند.
یک نقش شامل مجموعه ای از مجوزها است که به شما امکان می دهد اقدامات خاصی را روی منابع پروژه انجام دهید. ویرایشگرهای پروژه مجوزهایی برای اقداماتی دارند که حالت را تغییر می دهند، مانند امکان ایجاد تغییر در صفحه رضایت OAuth پروژه شما. صاحبان پروژه که همه مجوزهای ویرایشگر را دارند می توانند حساب های مرتبط با پروژه را اضافه یا حذف کنند یا پروژه را حذف کنند. صاحبان پروژه همچنین می توانند زمینه ای را برای اینکه چرا اطلاعات صورتحساب ممکن است تنظیم شود، ارائه دهند. صاحبان پروژه می توانند اطلاعات صورتحساب را برای پروژه ای که از API های پولی استفاده می کند تنظیم کنند.
صاحبان پروژه و ویراستاران باید به روز نگه داشته شوند. میتوانید چندین حساب مرتبط به پروژه خود اضافه کنید تا از دسترسی مداوم به پروژه و تعمیر و نگهداری مرتبط اطمینان حاصل کنید. زمانی که اعلانهایی درباره پروژه شما یا بهروزرسانیهای سرویسهای ما وجود دارد، به آن حسابها ایمیل میفرستیم. سرپرستان سازمان Google Cloud باید اطمینان حاصل کنند که یک مخاطب قابل دسترسی با هر پروژه در سازمان آنها مرتبط است. اگر اطلاعات تماس بهروز برای پروژه شما نداریم، ممکن است پیامهای مهمی را که نیاز به اقدام شما دارند، از دست بدهید.
هویت خود را به طور دقیق نشان دهید
یک نام برنامه معتبر و در صورت تمایل، یک لوگو برای نمایش به کاربران ارائه دهید. این اطلاعات برند باید دقیقاً نشان دهنده هویت برنامه شما باشد. اطلاعات نام تجاری برنامه از OAuth Consent Screen pageپیکربندی شده است.
برای برنامههای تولیدی، اطلاعات برند تعریفشده در صفحه رضایت OAuth شما باید قبل از نمایش به کاربران تأیید شود . ممکن است پس از تکمیل تأیید نام تجاری، کاربران به برنامه شما اجازه دسترسی بدهند. اطلاعات اولیه برنامه، که شامل نام، صفحه اصلی، شرایط خدمات و خطمشی رازداری برنامه است، به کاربران در صفحه کمک هزینه، زمانی که کمکهای مالی موجود خود را بررسی میکنند، یا به مدیران Google Workspace که استفاده از برنامه توسط سازمانشان را بررسی میکنند، نشان داده میشود.
Google میتواند دسترسی به سرویسهای API Google و سایر محصولات و سرویسهای Google را برای برنامههایی که هویت آنها را نادرست معرفی میکنند یا سعی در فریب کاربران دارند لغو یا تعلیق کند.
فقط دامنه هایی را که نیاز دارید درخواست کنید
در طول توسعه برنامه خود، ممکن است از یک محدوده نمونه ارائه شده توسط API برای ایجاد یک اثبات مفهومی در برنامه خود استفاده کرده باشید تا در مورد ویژگی ها و عملکرد API بیشتر بدانید. این محدودههای نمونه اغلب اطلاعات بیشتری نسبت به اجرای نهایی نیازهای برنامه شما درخواست میکنند، زیرا پوشش جامعی از تمام اقدامات ممکن برای یک API خاص ارائه میکنند. برای مثال، محدوده مثال ممکن است مجوز خواندن، نوشتن و حذف را درخواست کند در حالی که برنامه شما فقط به مجوزهای خواندن نیاز دارد. مجوزهای مربوطه را درخواست کنید که محدود به اطلاعات حیاتی لازم برای اجرای برنامه شما باشد.
مستندات مرجع را برای نقاط پایانی API که برنامه شما فراخوانی میکند، مرور کنید و به محدودههایی که برای دسترسی به دادههای مربوطه نیاز دارد توجه کنید. راهنماهای مجوزی را که API ارائه میدهد مرور کنید و دامنه آنها را با جزئیات بیشتری توصیف کنید تا رایجترین موارد استفاده را شامل شود. حداقل دسترسی به داده ای را که برنامه شما برای تقویت ویژگی های مرتبط به آن نیاز دارد، انتخاب کنید.
برای کسب اطلاعات بیشتر در مورد این الزام، بخش فقط دامنههای درخواستی که به آنها نیاز دارید از سیاستهای OAuth 2.0، به همراه بخش درخواست مجوزهای مربوطه از خطمشی دادههای کاربر سرویسهای API Google را بخوانید.
برنامههای تولیدی را ارسال کنید که از محدودههای حساس یا محدود برای تأیید استفاده میکنند
محدودههای خاصی بهعنوان «حساس» یا «محدود» طبقهبندی میشوند و نمیتوانند بدون بررسی در برنامههای تولیدی استفاده شوند. همه حوزههایی را که برنامه تولیدتان استفاده میکند در پیکربندی صفحه رضایت OAuth وارد کنید. اگر برنامه تولیدی شما از حوزههای حساس یا محدود استفاده میکند، قبل از اینکه دامنهها را در درخواست مجوز بگنجانید، باید استفاده خود از این حوزهها را برای تأیید ارسال کنید.
فقط از دامنه های خود استفاده کنید
فرآیند تأیید صفحه رضایت OAuth Google به تأیید همه دامنههای مرتبط با صفحه اصلی پروژه، خطمشی رازداری، شرایط خدمات، URIهای مجاز تغییر مسیر یا مبداهای مجاز جاوا اسکریپت نیاز دارد. فهرست دامنههایی را که برنامهتان استفاده میکند، خلاصهشده در بخش دامنههای مجاز ویرایشگر صفحه رضایت OAuth مرور کنید و دامنههایی را که متعلق به شما نیست و بنابراین نمیتوانید تأیید کنید، شناسایی کنید. برای تأیید مالکیت دامنههای مجاز پروژه خود، از کنسول جستجوی Google استفاده کنید. از یک حساب Google که با پروژه API Console شما مرتبط است به عنوان مالک یا ویرایشگر استفاده کنید.
اگر پروژه شما از یک ارائهدهنده خدمات با دامنه مشترک و مشترک استفاده میکند، توصیه میکنیم تنظیماتی را فعال کنید که امکان استفاده از دامنه خود را فراهم میکند. برخی از ارائه دهندگان پیشنهاد می کنند خدمات خود را به یک زیر دامنه از دامنه ای که قبلاً مالک آن هستید، نگاشت کنند.
یک صفحه اصلی برای برنامه های تولیدی میزبانی کنید
هر برنامه تولیدی که از OAuth 2.0 استفاده می کند باید یک صفحه اصلی در دسترس عموم داشته باشد. کاربران بالقوه برنامه شما ممکن است برای کسب اطلاعات بیشتر در مورد ویژگی ها و عملکردی که برنامه ارائه می دهد، از صفحه اصلی بازدید کنند. کاربران موجود ممکن است فهرست کمک های مالی موجود خود را مرور کنند و به عنوان یادآوری استفاده مداوم از پیشنهاد شما، از صفحه اصلی برنامه شما بازدید کنند.
صفحه اصلی برنامه شما باید شامل شرحی از عملکرد برنامه و همچنین پیوندهایی به خط مشی رازداری و شرایط اختیاری خدمات باشد. صفحه اصلی باید در یک دامنه تأیید شده تحت مالکیت شما وجود داشته باشد.
از URI های هدایت مجدد ایمن و مبدا جاوا اسکریپت استفاده کنید
مشتریان OAuth 2.0 برای برنامه های وب باید داده های خود را با استفاده از URI های تغییر مسیر HTTPS و مبدا جاوا اسکریپت ایمن کنند، نه HTTP ساده. Google میتواند درخواستهای OAuth را که از یک زمینه امن منشأ نمیگیرند یا به آنها رسیدگی نمیکنند، رد کند.
در نظر بگیرید که کدام برنامهها و اسکریپتهای شخص ثالث ممکن است به نشانهها و سایر اطلاعات کاربری که به صفحه شما بازمیگردند دسترسی داشته باشند. دسترسی به دادههای حساس را با مکانهای URI تغییر مسیر که به تأیید و ذخیره دادههای رمز محدود میشود، محدود کنید.
مراحل بعدی
پس از اینکه مطمئن شدید که برنامه شما با خطمشیهای OAuth 2.0 در این صفحه مطابقت دارد، برای جزئیات در مورد فرآیند تأیید ، به ارسال برای تأیید نام تجاری مراجعه کنید.