هنگامی که آماده استقرار راه حل پیاده سازی شده خود فراتر از محیط توسعه خود برای کاربران برنامه خود هستید، ممکن است لازم باشد اقدامات بیشتری را برای مطابقت با سیاست های 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 در این صفحه مطابقت دارد، برای جزئیات در مورد فرآیند تأیید ، به ارسال برای تأیید نام تجاری مراجعه کنید.
،هنگامی که آماده استقرار راه حل پیاده سازی شده خود فراتر از محیط توسعه خود برای کاربران برنامه خود هستید، ممکن است لازم باشد اقدامات بیشتری را برای مطابقت با سیاست های 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 در این صفحه مطابقت دارد، برای جزئیات در مورد فرآیند تأیید ، به ارسال برای تأیید نام تجاری مراجعه کنید.
،هنگامی که آماده استقرار راه حل پیاده سازی شده خود فراتر از محیط توسعه خود برای کاربران برنامه خود هستید، ممکن است لازم باشد اقدامات بیشتری را برای مطابقت با سیاست های 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 در این صفحه مطابقت دارد، برای جزئیات در مورد فرآیند تأیید ، به ارسال برای تأیید نام تجاری مراجعه کنید.
،هنگامی که آماده استقرار راه حل پیاده سازی شده خود فراتر از محیط توسعه خود برای کاربران برنامه خود هستید، ممکن است لازم باشد اقدامات بیشتری را برای مطابقت با سیاست های 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 که استفاده از برنامه توسط سازمان خود را بررسی می کنند ، به کاربران در صفحه کمک هزینه نشان داده شده است.
Google می تواند دسترسی به خدمات Google API و سایر محصولات و خدمات Google را برای برنامه هایی که هویت آنها را نادرست نشان می دهند یا تلاش برای فریب کاربران را لغو یا به حالت تعلیق درآورده اند ، لغو یا تعلیق کند.
فقط دامنه هایی را که لازم دارید درخواست کنید
در حین توسعه برنامه ، شما ممکن است از یک نمونه نمونه تهیه شده توسط API برای ایجاد اثبات مفهوم در برنامه خود استفاده کرده باشید تا در مورد ویژگی ها و عملکرد API اطلاعات بیشتری کسب کنید. این نمونه های نمونه اغلب اطلاعات بیشتری را نسبت به اجرای نهایی نیازهای برنامه شما درخواست می کنند ، زیرا آنها پوشش کاملی از کلیه اقدامات ممکن را برای یک API خاص ارائه می دهند. به عنوان مثال ، دامنه مثال ممکن است مجوزهای خواندن ، نوشتن و حذف مجوزها را درخواست کند در حالی که برنامه شما فقط به مجوزهای خوانده شده نیاز دارد. مجوزهای مربوطه را که محدود به اطلاعات مهم لازم برای اجرای برنامه شما است ، درخواست کنید .
مستندات مرجع را برای نقاط پایانی API که برنامه شما با آنها تماس می گیرد ، مرور کنید و به دامنه هایی که برای دسترسی به داده های مربوط به برنامه شما نیاز دارند ، توجه داشته باشید. راهنماهای مجوز را که API ارائه می دهد را مرور کنید و با جزئیات بیشتری دامنه های خود را توصیف کنید تا رایج ترین استفاده را شامل شود. حداقل دسترسی به داده را که برنامه شما برای برقراری ویژگی های مرتبط نیاز دارد ، انتخاب کنید.
برای کسب اطلاعات بیشتر در مورد این نیاز ، تنها Scopes درخواست را که به بخش خط مشی OAUTH 2.0 نیاز دارید ، همراه با بخش مجوزهای مربوط به خط مشی داده های کاربر Google API ، بخوانید.
برنامه های تولیدی را که از دامنه های حساس یا محدود برای تأیید استفاده می کنند ارسال کنید
برخی از دامنه ها به عنوان "حساس" یا "محدود" طبقه بندی می شوند و بدون بررسی در برنامه های تولیدی قابل استفاده نیستند. تمام دامنه هایی را که برنامه تولید خود را در پیکربندی صفحه رضایت OAUTH خود استفاده می کند ، وارد کنید. اگر برنامه تولیدی شما از دامنه های حساس یا محدود استفاده می کند ، باید قبل از اینکه Scopes را در یک درخواست مجوز قرار دهید ، استفاده خود را از آن Scopes برای تأیید ارسال کنید.
فقط از دامنه های خود استفاده کنید
فرآیند تأیید صفحه رضایت OAUTH Google نیاز به تأیید کلیه حوزه های مرتبط با صفحه اصلی پروژه شما ، خط مشی رازداری ، شرایط خدمات ، URI های هدایت شده مجاز یا منشاء مجاز جاوا اسکریپت دارد. لیست دامنه های مورد استفاده توسط برنامه خود را ، خلاصه شده در بخش مجاز دامنه های ویرایشگر صفحه رضایت OAUTH را مرور کنید و هر دامنه ای را که متعلق به آن نیستید شناسایی کنید و بنابراین قادر به تأیید آن نیستید. برای تأیید مالکیت دامنه های مجاز پروژه خود ، از کنسول جستجوی Google استفاده کنید. از یک حساب Google استفاده کنید که با شما همراه باشد API Console پروژه به عنوان مالک یا ویرایشگر.
اگر پروژه شما از ارائه دهنده خدمات با دامنه مشترک و مشترک استفاده می کند ، توصیه می کنیم تنظیماتی را فعال کنید که امکان استفاده از دامنه خود را فراهم کند. برخی از ارائه دهندگان پیشنهاد می دهند خدمات خود را به زیر دامنه دامنه ای که قبلاً در اختیار دارید ، نقشه برداری کنند.
میزبان یک صفحه اصلی برای برنامه های تولید
هر برنامه تولیدی که از OAUTH 2.0 استفاده می کند باید یک صفحه اصلی در دسترس عمومی داشته باشد. کاربران بالقوه برنامه شما ممکن است برای کسب اطلاعات بیشتر در مورد ویژگی ها و عملکردی که برنامه ارائه می دهد ، از صفحه اصلی بازدید کنند. کاربران موجود ممکن است لیست خود را از کمک های مالی موجود بررسی کرده و از صفحه اصلی برنامه شما به عنوان یادآوری استفاده مداوم از پیشنهادات شما بازدید کنند.
صفحه اصلی برنامه شما باید شامل توضیحی در مورد عملکرد برنامه و همچنین پیوندهایی به یک خط مشی رازداری و شرایط خدمات اختیاری باشد. صفحه اصلی باید در یک دامنه تأیید شده تحت مالکیت شما وجود داشته باشد.
از URI های تغییر مسیر ایمن و منشأ جاوا اسکریپت استفاده کنید
مشتریان OAUTH 2.0 برای برنامه های وب باید داده های خود را با استفاده از HTTPS تغییر مسیر URIS و منشأ جاوا اسکریپت ، و نه HTTP ساده ، تأمین کنند. Google می تواند درخواست های OAUTH را که از سرچشمه یا حل و فصل در یک زمینه امن استفاده نمی کنند ، رد کند.
در نظر بگیرید که کدام برنامه ها و اسکریپت های شخص ثالث ممکن است به نشانه ها و سایر اعتبار کاربر که به صفحه شما باز می گردند دسترسی داشته باشند. دسترسی به داده های حساس را با مکان های تغییر مسیر URI که محدود به تأیید و ذخیره داده های توکن هستند محدود کنید.
مراحل بعدی
پس از اطمینان از اینکه برنامه شما با خط مشی های OAUTH 2.0 در این صفحه مطابقت دارد ، برای جزئیات بیشتر در مورد فرآیند تأیید ، به ارسال تأیید برند مراجعه کنید.