این راهنمای گام به گام به شما کمک می کند تا در مورد تمام مسائل اصلی یکپارچه سازی تصمیم گیری کنید.
به صورت چکیده با گوگل وارد شوید
در زیر مراحل کلی برای ورود کاربران به سایت / ثبت نام در وب سایت شما آورده شده است.
کاربران وارد یک وب سایت گوگل می شوند.
برای اینکه Sign in with Google کار کند، باید یک جلسه Google فعال در مرورگر وجود داشته باشد. یک ضربه و ورود خودکار تنها زمانی فعال می شوند که کاربران قبل از بارگیری صفحات وب شما به سیستم Google وارد شده باشند. این مرحله برای جریان دکمه Sign in with Google اختیاری است، زیرا با فشار دادن دکمه از کاربران خواسته میشود وارد Google شوند.
کاربران صفحات وب شما را مرور می کنند که در آن دکمه One Tap، Automatic Sign-in یا Sign in with Google تعبیه شده است.
کاربران با One Tap، دکمه Sign in with Google و جریان های UX بعدی به این ترتیب تعامل دارند:
- برای ادامه، یک جلسه فعال Google را انتخاب کنید.
- از کاربران نهایی برای به اشتراک گذاری اطلاعات نمایه با وب سایت خود رضایت بگیرید، اگر هنوز رضایت نداده اند.
هنگامی که تنها یک جلسه Google فعال در مرورگر وجود دارد،
- One Tap تنها جلسه را به طور خودکار انتخاب می کند و بنابراین از صفحه انتخابگر حساب پرش می شود.
- دکمه Sign in with Google در صفحه انتخابگر حساب باقی می ماند که به کاربران امکان می دهد در صورت نیاز یک جلسه جدید Google اضافه کنند.
اگر حساب Google انتخاب شده قبلاً برای وب سایت شما استفاده نشده باشد یا مجوز لغو شده باشد، صفحه رضایت نمایش داده می شود.
پس از تأیید، Google تصمیم را ثبت می کند تا برای دفعه بعد از صفحه رضایت رد شود.
اعتبارنامه JSON Web Token (که به آن شناسه شناسه نیز میگویند) حاوی نام، ایمیل و تصویر نمایه کاربر، با استفاده از کنترلکننده پاسخ به تماس جاوا اسکریپت یا ارسال پست به سرویس پشتیبان شما به اشتراک گذاشته میشود.
هدف از بازگرداندن شناسههای شناسه به کنترلکننده پاسخ به تماس جاوا اسکریپت در سمت کلاینت، این نیست که شما آن را در کد جاوا اسکریپت رمزگشایی کنید، بلکه این است که به روش خودتان آن را به سرور خود ارسال کنید. یک مثال خوب استفاده از XmlHttpRequest برای جلوگیری از بارگذاری مجدد صفحه ناشی از ارسال پست است.
در سمت سرور شما، اعتبار JWT صادر شده توسط Google برای ایجاد یک حساب کاربری جدید یا ایجاد یک جلسه تأیید اعتبار در وبسایت شما تأیید و مصرف میشود.
شما وضعیت ورود به سیستم کاربر را در وب سایت خود مدیریت خواهید کرد.
وضعیت ورود به سیستم حساب Google کاربر و برنامه شما مستقل از یکدیگر هستند، مگر در زمان ورود به سیستم که می دانید کاربر با موفقیت احراز هویت شده و به حساب Google خود وارد شده است. کاربران ممکن است همچنان وارد سیستم شوند، ممکن است از سیستم خارج شوند یا در حالی که یک جلسه فعال و با ورود به سیستم در وب سایت شما حفظ می کنند، به یک حساب Google دیگر تغییر کاربری دهند.
به طور خلاصه، مانند ورود مبتنی بر رمز عبور، Sign in with Google راه دیگری برای احراز هویت کاربران در وب ارائه می دهد . ورود با Google هیچ ویژگی برای مدیریت جلسه در وب سایت شما پس از احراز هویت ارائه نمی دهد.
به APIها و خدمات Google دسترسی داشته باشید
همانطور که در بالا توضیح داده شد، در حالی که API احراز هویت را ادغام کرده اید، ممکن است نیاز به ادغام API مجوز نیز داشته باشید، اگر سایت شما نیاز به دسترسی به APIها و خدمات Google از طرف کاربران احراز هویت شده داشته باشد. در حالی که احراز هویت برای احراز هویت کاربران، نشانههای شناسه را برای سایت شما فراهم میکند، مجوز به سایت شما نشانههای دسترسی (جدا) و مجوزهای استفاده از APIها و سرویسهای Google را میدهد. برای اطلاعات بیشتر به مجوز برای وب مراجعه کنید.
جداسازی UX برای احراز هویت و مجوز
اگر وب سایت شما نیاز به فراخوانی APIهای احراز هویت و مجوز دارد، باید آنها را به طور جداگانه در لحظات مختلف فراخوانی کنید. به جداسازی لحظات احراز هویت و مجوز مراجعه کنید.
اگر وبسایت شما در گذشته توکنهای احراز هویت و مجوز را با هم درخواست کرده است، هنگام استفاده از کتابخانه جاوا اسکریپت سرویسهای هویت Google، باید UX خود را طوری تنظیم کنید که لحظه احراز هویت را از لحظه مجوز جدا کنید.
- در لحظه احراز هویت، وب سایت شما می تواند با دکمه One Tap، Automatic Sign-in یا Sign in with Google ادغام شود تا کاربران بتوانند وارد وب سایت شما شوند یا ثبت نام کنند.
- در لحظه مجوز، وبسایت شما میتواند از API مجوز برای دریافت مجوزها و نشانههای دسترسی به APIها یا خدمات Google استفاده کند.
برای انتقال نرم افزار UX و کاهش پیچیدگی، یک روش معمول این است که فرآیند را به دو مرحله مجزا تقسیم کنیم.
- برای جداسازی لحظات احراز هویت و مجوز، UX را بازسازی کنید.
به کتابخانه جاوا اسکریپت Google Identity Services مهاجرت کنید.
HTML API در مقابل JavaScript API
می توانید از HTML API یا JavaScript API برای ادغام دکمه One Tap، Automatic Sign in یا Sign In With Google در صفحات وب خود استفاده کنید.
با HTML API، ویژگی های داخلی بیشتری دارید. مثلا،
- رندر کردن با یک ضربه یا دکمه Sign in With Google در بارگذاری صفحه.
- پس از انجام One Tap، Automatic Sign-in یا دکمه pop-up/redirect UX، اعتبار برگشتی را به نقطه پایانی سمت سرور خود، که با ویژگی
data-login_uri
مشخص شده است، ارسال کنید. - جلوگیری از حملات CSRF توسط double-submit-cookie .
- از تولید کننده کد برای تولید کد HTML استفاده کنید، سپس فقط آن را در صفحات HTML خود کپی کنید.
با HTML API، شما همچنین می توانید مقداری جاوا اسکریپت برای سفارشی کردن رفتار بنویسید.
میتوانید کنترلکننده پاسخ به تماس خود را بنویسید، سپس نام تابع را روی ویژگی
data-callback
تنظیم کنید. یک مثال خوب این است که از XmlHttpRequest برای ارسال اعتبار برگشتی به سرور خود استفاده کنید تا از بارگذاری مجدد صفحه ناشی از ارسال پست پیش فرض جلوگیری کنید.
با جاوا اسکریپت API، در برخی از سناریوهای زیر انعطاف بیشتری دارید.
- رندر کردن با یک ضربه و دکمه ورود با Google در لحظهای بعد. به عنوان مثال، پس از اینکه کاربران، Login را از منو انتخاب کردند.
- چندین بار با API تماس بگیرید. به عنوان مثال، هر بار که گفتگوی ورود ارائه می شود، باید دکمه Sign in with Google ارائه شود.
- صفحات HTML خود را به صورت پویا ایجاد می کنید، که جاسازی کد فراخوانی API در آنها را دشوار می کند.
- شما کتابخانه جاوا اسکریپت خدمات هویت گوگل را در زمان بسیار کمی بارگیری می کنید.
کد HTML API را فقط می توان یک بار در رویداد بارگذاری صفحه یا رویداد بارگذاری کتابخانه جاوا اسکریپت خدمات هویت Google، هر کدام که بعداً اتفاق بیفتد، فراخوانی کرد. اگر رفتار HTML API انتظار شما را برآورده نمی کند، باید از JavaScript API استفاده کنید.
از API HTML با API جاوا اسکریپت در همان صفحه وب برای مقداردهی اولیه صفحه یا برای رندر کردن با یک ضربه و دکمه استفاده نکنید. کدهای خود را، هم HTML و هم جاوا اسکریپت، برای جاهایی که ممکن است با هم تداخل داشته باشند، بررسی کنید. به موارد زیر توجه کنید:
- اگر یک یا چند عنصر در
<div id='g_id_onload' ... ><id>
یا<div class='g_id_signin' ...></div>
در کد HTML شما وجود داشته باشد، از HTML API استفاده می کنید. - اگر یک یا چند روش در
initialize()
,prompt()
یاrender()
در کد جاوا اسکریپت شما فراخوانی شده باشد، صرف نظر از اینکه از یک فایل جاوا اسکریپت جدا شده اند یا بارگذاری شده باشند، از JavaScript API استفاده می کنید.
APIهای جاوا اسکریپت زیر ممکن است مستقل از مقداردهی اولیه یا رندر با یک ضربه و دکمه استفاده شوند. اینها APIهای HTML مربوطه ندارند:
با ملاحظات دکمه Google وارد شوید
پاپ آپ در مقابل تغییر مسیر
مشخصات OAuth 2.0 تغییر مسیر HTTP را در نظر می گیرد، اما فاقد راهنمایی در مورد ارائه گفتگوهای پاپ آپ است. UX پاپ آپ، به ویژه در وب دسکتاپ، ممکن است UX بهتری را برای کاربران نهایی فراهم کند. این به این دلیل است که کاربران به دور از صفحات شخص ثالث هدایت نمی شوند، و یک پنجره بازشو مانند گفتگو، تجربه ای درون زمینه ای برای اعطای مجوز فراهم می کند.
با UX پاپآپ، ارائهدهنده هویت باید بر روی کانالهای ارتباطی متقاطع سمت کلاینت ایجاد کند تا پاسخهای OAuth را از پنجره بازشو، جایی که صفحه رضایت ارائهدهنده هویت نمایش داده میشود، به پنجره اصلی، جایی که سومی است، منتقل کند. صفحه حزب در حال نمایش است. معمولاً کدهای جاوا اسکریپت از هر دو طرف برای ارسال و دریافت پاسخ OAuth در پنجره ها مورد نیاز است.
هر دو UX پاپ آپ و تغییر مسیر توسط دکمه Sign in with Google پشتیبانی می شوند. به طور پیش فرض، UX پاپ آپ استفاده می شود. با تنظیم ویژگی data-ux_mode
می توانید UX را تغییر دهید.
بین جریان تغییر مسیر دکمه Sign in with Google و جریان تغییر مسیر OAuth تفاوت هایی وجود دارد.
- جریان تغییر مسیر دکمه Sign in with Google همیشه از روش
POST
برای ارسال اعتبار به سرور وب شما استفاده می کند، در حالی که تغییر مسیر OAuth معمولاً از روشGET
استفاده می کند. - پارامترهای ارسال شده توسط جریان تغییر مسیر دکمه Sign in with Google با پارامترهای جریان تغییر مسیر OAuth متفاوت است.
برای توسعه دهندگانی که از HTML API استفاده می کنند، صرف نظر از اینکه از کدام UX استفاده می شود، اعتبارنامه ها همیشه با روش POST
و همان پارامترها به data-login_uri
ارسال می شوند. این به شما امکان می دهد حالت UX را بدون تغییر کد دیگر تغییر دهید. برای تغییر مسیر UX، data-login_uri
باید به URIهای مجاز تغییر مسیر برای مشتری شما در کنسول Google APIs اضافه شود.
سفارشی سازی دکمه
استفاده از دکمه شخصی شما پشتیبانی نمی شود. هیچ API برای شروع برنامهریزی یک جریان دکمه وجود ندارد.
برای فعال کردن جریان دکمه Sign in with Google، تنها کاری که باید انجام دهید این است که یک یا چند دکمه Sign in with Google را در صفحات وب خود ارائه دهید. وقتی کاربران روی این دکمهها کلیک میکنند، جریان دکمه شروع و بهطور شفاف مدیریت میشود.
API رندر دکمه به شما امکان می دهد ظاهر و احساس دکمه ورود با Google را سفارشی کنید. برای طراحی تعاملی دکمه های خود به شما توصیه می شود از تولید کننده کد استفاده کنید. حتی اگر از JavaScript API استفاده می کنید، می توانید ابتدا کد HTML را تولید کنید، سپس کد را در فیلدهای مربوطه در JavaScript API کپی کنید.
هیچ API وجود ندارد که به وبسایتها اجازه دهد کنترل کنند که آیا اطلاعات شخصیشده باید برای نمایش دکمهها استفاده شود یا خیر. در صورت رعایت همه شرایط، دکمه های شخصی سازی شده نمایش داده می شوند. جزئیات بیشتر در دکمه درک شخصی سازی شده است .
می توانید چندین دکمه را در یک صفحه وب قرار دهید. مولد کد هر بار فقط می تواند یک دکمه ایجاد کند. می توانید چندین بار آن را اجرا کنید و کد <div class='g_id_signin' ...></div>
ایجاد شده را در صفحه وب کپی کنید.
بهترین شیوه های ارائه دکمه
به دلایل حفظ حریم خصوصی، دکمه شخصیشده در یک iframe از دامنه accounts.google.com نشان داده میشود. بارگذاری iframe ممکن است در یک شبکه کند زمانبر باشد. برای کاهش این مشکل تاخیر، دکمه ها در 2 مرحله به شرح زیر ارائه می شوند:
- یک نسخه دکمه درون خطی در درخت DOM وب سایت شما ارائه می شود. این فقط یک دکمه متن است، هیچ اطلاعات شخصی نمی تواند استفاده شود. هدف این است که کاربران بتوانند دکمه را در اسرع وقت ببینند.
- یک درخواست iframe به Google ارسال میشود تا دکمه iframe را بارگیری کند، که ممکن است اطلاعات شخصیشده داشته باشد. پس از بارگیری دکمه iframe، دکمه نسخه درون خطی حذف می شود.
برخی از بهترین روشها برای به حداقل رساندن تأخیر نمایش دکمه جریان دکمه ورود با Google در زیر فهرست شدهاند.
- کتابخانه جاوا اسکریپت خدمات هویت گوگل را در اسرع وقت بارگیری کنید. بارگذاری کتابخانه جاوا اسکریپت را قبل از چند کتابخانه بزرگ دیگر، به ویژه در وب موبایل، در نظر بگیرید.
اگر دکمه Sign in with Google تنها پس از انتخاب کاربر Login از منو ارائه شود. میتوانید ابتدا دکمه Sign in with Google را در یک عنصر مخفی رندر کنید، سپس بعد از اینکه کاربر Login را از منو انتخاب کرد، آن را قابل مشاهده کنید.
ملاحظات یک شیر
ورود خودکار
ورود به سیستم خودکار قابل لغو مزایای زیر را ارائه می دهد.
- ممکن است با ذخیره یک اقدام کاربر، نرخ ورود به سیستم را بهبود بخشد.
- برخلاف ورود به سیستم بیصدا ارائه شده توسط کتابخانه جاوا اسکریپت Google Sign-In قبلی، کاربران همیشه در هنگام ورود به سیستم خودکار، برخی از رابطهای کاربری را مشاهده میکنند که به آنها توضیح میدهد چرا و چگونه به وبسایت شما وارد شدهاند. همچنین کاربران در صورت تمایل می توانند آن را لغو کنند.
- به طور خودکار حسابی را که کاربر قبلاً استفاده کرده بود انتخاب می کند، که ممکن است مانع از ایجاد حساب های تکراری در وب سایت شما شود.
اینکه آیا ورود خودکار را فعال کنید یا نه تصمیمی است که باید بر اساس UX و الزامات تجاری وب سایت خود بگیرید. به خصوص اگر بیشتر خروجها از وبسایت شما بهجای انتخابهای صریح کاربر، بهدلیل توقف جلسه باشد، ورود خودکار ممکن است راه خوبی برای کاربران شما برای بازیابی وضعیت جلسه باشد.
زمان نمایش رابط کاربری One Tap
با HTML API، One Tap همیشه در بارگذاری صفحه نمایش داده می شود. با جاوا اسکریپت API، می توانید کنترل کنید که چه زمانی رابط کاربری One Tap نمایش داده می شود. توجه داشته باشید که ممکن است به دلایلی که در زیر توضیح داده شده است، رابط کاربری One Tap همیشه پس از فراخوانی API نمایش داده نشود.
- هیچ جلسه Google فعالی در مرورگر وجود ندارد.
- تمام جلسات فعال Google انصراف داده شده است.
- Cooldown در حال انجام است.
سعی نکنید فقط رابط کاربری One Tap را در رویداد کلیک دکمه نمایش دهید. رابط کاربری One Tap ممکن است به دلایل بالا نمایش داده نشود و کاربران ممکن است UX خرابی داشته باشند، زیرا هیچ چیزی بعد از اقدام کاربر نمایش داده نمی شود. در رویداد کلیک دکمه:
توصیه شده
- گفتگوی ورود خود را با ورود رمز عبور و دکمه ورود با Google نشان دهید و همزمان با One Tap API تماس بگیرید. این تضمین می کند که همیشه روشی برای ورود به وب سایت شما به کاربران ارائه می شود.
توصیه نمیشود
- با ارائه تنها One Tap، اگر One Tap نمایش داده نشود، کاربران ممکن است یک تجربه ورود به سیستم شکسته را تجربه کنند.
- اگر One Tap نمایش داده نشد ، از پاسخ تماس وضعیت رابط کاربری برای نشان دادن رابط کاربری دیگر استفاده کنید. این توصیه نمیشود، زیرا ممکن است در نسخههای بعدی، پاسخ تماس وضعیت رابط کاربری به خوبی با مدیریت اعتبار فدرال کار نکند.
یک ضربه بر روی مرورگرهای ITP
به دلیل پیشگیری از ردیابی هوشمند (ITP)، UX معمولی One Tap در مرورگرهای ITP مانند Chrome در iOS، Safari و Firefox کار نمی کند. به جای آن یک UX متفاوت که با صفحه خوش آمدگویی شروع می شود در این مرورگرها ارائه می شود.
در صورت تمایل میتوان One Tap UX را در مرورگرهای ITP غیرفعال کرد. برای جزئیات بیشتر به پشتیبانی One Tap در مرورگرهای ITP مراجعه کنید.
هیچ راهی برای فعال کردن این UX در مرورگرهای غیر ITP، مانند Chrome در Android/macOS/Linux و Edge وجود ندارد.
اگر کاربر کلیک کرد، درخواست را لغو کنید
به طور پیش فرض، اگر کاربر خارج از اعلان کلیک کند، درخواست One Tap به طور خودکار بسته می شود. در صورت تمایل می توان این رفتار را تغییر داد.
به شما توصیه می شود اعلان One Tap را در وب دسکتاپ باز نگه دارید، زیرا اندازه صفحه به اندازه کافی بزرگ است.
موقعیت One Tap UX را تغییر دهید
در وب دسکتاپ، میتوانید موقعیت درخواست One Tap را تغییر دهید . با این حال، این ویژگی توصیه نمی شود زیرا این ویژگی توسط مدیریت اعتبار فدرال در نسخه های بعدی پشتیبانی نمی شود.
زمینه ورود به سیستم را تغییر دهید
One Tap باید بخشی از یک جریان UX بزرگتر در وب سایت شما باشد. به طور پیش فرض، رابط کاربری One Tap در یک زمینه ورود به سیستم استفاده می شود. زبان در UI حاوی عبارات خاصی است، مانند "ورود به سیستم". می توانید ویژگی متن را تغییر دهید تا مجموعه متفاوتی از جمله بندی ایجاد کنید. میتوانید یکی از هدرهای One Tap را انتخاب کنید که به بهترین وجه با جریان UX شما مطابقت دارد.
متن نوشته | |
---|---|
signin | "ورود با گوگل" |
signup | "ثبت نام با گوگل" |
use | "استفاده با گوگل" |
در وضعیت رابط کاربری One Tap گوش دهید
برای ادغام یکپارچه در جریان UX بزرگتر، One Tap می تواند هنگام تغییر وضعیت رابط کاربری به شما اطلاع دهد . با این حال، این ویژگی در نسخه های مدیریت اعتبارنامه فدرال آینده پشتیبانی نمی شود.
یک ضربه روی زیر دامنه ها
بهطور پیشفرض، خنککردن با یک ضربه و سایر وضعیتها در هر مبدأ ردیابی میشوند. اگر وب سایت شما One Tap را در چندین زیردامنه نمایش می دهد، باید آن را در کد API خود نشان دهید.
یک ضربه در صفحات HTML ایستا
به طور پیشفرض، کتابخانه GIS فرض میکند که صفحات وب شما به صورت پویا تولید میشوند. سرور HTTP شما هنگام تولید کد HTML وضعیت ورود کاربر را بررسی می کند.
- اگر هیچ کاربری وارد نشده است، کد One Tap HTML باید در صفحه حاصل گنجانده شود تا با فعال کردن One Tap به کاربران اجازه ورود به وب سایت شما را بدهد.
- اگر کاربران قبلاً وارد سیستم شدهاند، کد HTML One Tap نباید در صفحه ایجاد شده درج شود.
در این حالت، اضافه کردن یا حذف کد One Tap HTML API بر عهده وب سرور شما است.
کد One Tap HTML API می تواند به روش دیگری کار کند، که برای وب سایت هایی طراحی شده است که محتوای HTML ثابت زیادی را میزبانی می کنند. همیشه می توانید کد One Tap HTML API را در صفحات HTML ثابت خود قرار دهید و نام کوکی جلسه مورد استفاده در وب سایت خود را مشخص کنید.
- اگر کوکی جلسه وجود نداشته باشد، جریان One Tap فعال می شود.
- اگر کوکی جلسه وجود داشته باشد، جریان یک ضربه رد می شود.
در این حالت، بهجای وجود کد One Tap HTML API در صفحه وب، وضعیت کوکی جلسه شما کنترل میشود که جریان One Tap را فعال کنید.
ادغام سمت سرور
پس از یک ضربه، ورود خودکار به سیستم یا جریان UX دکمه Sign in with Google انجام شد، یک رمز شناسه صادر شده و با وب سایت شما به اشتراک گذاشته می شود. برای احراز هویت کاربر، برخی تغییرات سمت سرور برای دریافت و تأیید اعتبار شناسه مورد نیاز است.
ملاحظات UX
معمولاً باید یک نقطه پایانی HTTP در مبدا خود اضافه کنید تا پاسخهای سمت سرورتان را مدیریت کنید. عوامل زیر ممکن است بر UX حاصله تأثیر بگذارند.
- این که آیا یک ضربه یا ورود به سیستم با Google فعال می شود.
- چه از HTML API یا JavaScript API استفاده شود.
- آیا از URI ورود به سیستم یا تابع فراخوانی جاوا اسکریپت برای رسیدگی به پاسخ استفاده می شود.
UX واقعی که دریافت می کنید به شرح زیر است.
برای دکمه Sign in with Google Redirect mode UX:
- چه از HTML API یا JavaScript API استفاده شود، باید URI ورود به سیستم را تنظیم کنید. استفاده از تابع فراخوانی جاوا اسکریپت برای رسیدگی به پاسخ غیرممکن است، زیرا کاربران قبلاً از صفحه وب شما هدایت شده اند.
- خلاصه UX: پس از کلیک بر روی دکمه ورود با Google، کاربران یک تغییر مسیر تمام صفحه به یک رابط کاربری Google را برای انتخاب جلسه و تایید می بینند. پس از انجام، یک
POST
تمام صفحه به URI ورود به سیستمی که مشخص کرده اید ارسال می شود.
برای حالت UX پاپآپ با یک ضربه یا دکمه ورود با Google، اگر از JavaScript API استفاده میشود، یا از HTML API استفاده میشود و یک تابع فراخوان جاوا اسکریپت ارائه میشود:
- پاسخ های احراز هویت به تابع فراخوانی جاوا اسکریپت بازگردانده می شوند.
- خلاصه UX: درخواست One Tap یا یک پنجره پاپ آپ در بالای صفحه وب شما نشان داده می شود. پس از اینکه کاربران UX را در پنجره اعلان یا پاپ آپ برای انتخاب جلسه و تأیید به پایان رساندند، تابع فراخوانی جاوا اسکریپت پاسخ ها را دریافت می کند. UX بعدی بر اساس نحوه ارسال پاسخ ها به سرور شما توسط تابع پاسخ به تماس شما تعیین می شود.
در غیر این صورت (HTML API با مورد URI ورود):
- پاسخ های احراز هویت به URI ورود ارسال می شود.
- خلاصه UX: درخواست One Tap یا یک پنجره پاپ آپ در بالای صفحه وب شما نشان داده می شود. پس از اینکه کاربران UX را در پنجره اعلان یا پاپ آپ برای انتخاب جلسه و تایید به پایان رساندند، پاسخ های احراز هویت با استفاده از ارسال
POST
تمام صفحه به URL ورود به سیستمی که مشخص کرده اید ارسال می شود.
به شما توصیه میشود از روشی ثابت برای ارسال پاسخهای یک ضربه و دکمه ورود با Google استفاده کنید.
ملاحظات امنیتی
برای جلوگیری از حملات جعل درخواست بین سایتی ،
- برای ارسال پستی که توسط کتابخانه جاوا اسکریپت سرویس گیرنده Google Identity راه اندازی می شود، می توانید از الگوی داخلی دو ارسال-کوکی استفاده کنید. برای جزئیات بیشتر به تأیید نماد Google ID در سمت سرور خود مراجعه کنید.
- برای ارسال به مبدأ خود با استفاده از XmlHttpRequest، میتوانید از هدر HTTP سفارشی یا سایر اقدامات امنیتی تأیید شده توسط تیم امنیتی خود استفاده کنید.
برای تأیید نشانههای شناسه در پاسخهای احراز هویت، اکیداً به شما توصیه میشود از یک کتابخانه سرویس گیرنده Google API برای پلتفرم خود یا یک کتابخانه JWT همه منظوره استفاده کنید.
سوالات متداول (سؤالات متداول)
آیا دکمه One Tap and Sign in with Google در بازدیدهای وب موجود است؟
خیر. به دلیل نگرانی های امنیتی، کاربران نباید جلسات Google را به نمای وب اضافه کنند. بنابراین، GIS در وبنماها غیرفعال است، زیرا قرار نیست هیچ جلسه Google در آنجا باشد.
آیا می توانم از دکمه ورود به سیستم با Google خود استفاده کنم؟ خیر. با جریان سمت سرور OAuth یا نسخه قبلی کتابخانه جاوا اسکریپت ورود به سیستم Google، طرفهای متکی میتوانستند از دستورالعملهای نام تجاری ورود به سیستم برای ساختن نسخههای خود دکمههای ورود به سیستم Google استفاده کنند.
با این حال، Sign in with Google این ویژگی را حذف کرده است. همه دکمههای ورود با Google باید توسط کتابخانه جاوا اسکریپت سرویسهای هویت Google ایجاد شوند. دو دلیل برای این تغییر وجود دارد.
- برخی از طرفهای متکی از دستورالعملها پیروی نکردند، که منجر به ناسازگاری دکمههای ورود به سیستم با Google در سراسر وبسایتها میشود.
- با ایجاد توسط کتابخانه، زمانی که خود دستورالعملهای نام تجاری ورود به سیستم تغییر میکند، نیازی به ایجاد هیچ تغییری ندارید.
برای اجرای این قانون، کتابخانه جاوا اسکریپت فقط یک API را برای رندر کردن یک دکمه نمایش می دهد، اما نه API را برای شروع جریان ورود به سیستم.
اگر وبسایت من فقط یک ضربه را فعال کند اما دکمه ورود با Google را فعال نکند، چه؟
به شما توصیه می شود از دکمه One Tap و Sign in with Google در وب سایت خود استفاده کنید. به دلیل خنک شدن نمایی، ممکن است هر بار یک ضربه نمایش داده نشود. هنگامی که کاربران واقعاً می خواهند با حساب های Google خود وارد وب سایت شما شوند، می توانند به گفتگوی اصلی ورود به سیستم شما رفته و با دکمه Sign in with Google در آنجا وارد شوید. ورود موفقیت آمیز با استفاده از دکمه ورود به سیستم با Google، وضعیت خنک شدن One Tap را پاک می کند تا One Tap بتواند برای ورود بعدی نمایش داده شود. سایر جریانهای دکمهای از Google نمیتوانند وضعیتهای خنکسازی با یک ضربه را پاک کنند ، زیرا در باینریهای جاوا اسکریپت مختلف هستند.
اگر وبسایت شما فقط One Tap را فعال میکند اما دکمه ورود با Google را فعال نمیکند، ممکن است شاهد افت عملکرد برای جریان One Tap خود باشید، زیرا وضعیتهای خنکسازی نمایی به موقع پاک نمیشوند.
وقتی کد HTML API من تجزیه می شود؟ آیا می توانم کد HTML API خود را بعداً تغییر دهم؟
کتابخانه جاوا اسکریپت Google Identity Services کد HTML API شما را در رویداد بارگیری کتابخانه جاوا اسکریپت یا رویداد DomContentLoaded تجزیه و اجرا می کند.
- اگر رویداد DomContentLoaded هنگام بارگیری کتابخانه جاوا اسکریپت راه اندازی شود، کد HTML API شما بلافاصله تجزیه و اجرا می شود.
- در غیر این صورت، کتابخانه جاوا اسکریپت یک شنونده برای رویداد DomContentLoaded اضافه می کند. وقتی فعال می شود، شنونده کد HTML API شما را تجزیه و اجرا می کند.
همچنین توجه داشته باشید که تجزیه و اجرای کد HTML API شما یکبار است .
- پس از تجزیه و اجرا، هر گونه تغییر بعدی در کد HTML API شما نادیده گرفته می شود.
- هیچ API برای توسعه دهندگان وجود ندارد تا فرآیند تجزیه یا اجرا را راه اندازی کند.