تأثیر تغییرات کوکی شخص ثالث را بر گردش کار ورود به سیستم خود بررسی کنید

Chrome تجربه جدیدی را برای انتخاب کاربر با کوکی‌های شخص ثالث پیشنهاد می‌کند. شما باید سایت خود را برای کاربرانی که انتخاب می کنند بدون کوکی های شخص ثالث مرور کنند، آماده کنید.

در این صفحه اطلاعاتی در مورد سناریوهای هویتی که احتمالاً تحت تأثیر قرار می گیرند و همچنین ارجاعاتی به راه حل های ممکن را خواهید یافت.

اگر وب‌سایت شما فقط جریان‌های درون دامنه و زیردامنه‌های مشابه، مانند publisher.example و login.publisher.example را مدیریت می‌کند، از کوکی‌های بین‌سایتی استفاده نمی‌کند و انتظار نمی‌رود جریان ورود به سیستم شما تحت‌تاثیر سوم قرار گیرد. تغییرات کوکی مهمانی

با این حال، اگر سایت شما از یک دامنه جداگانه برای ورود استفاده می کند، مانند ورود به سیستم Google یا ورود به فیس بوک ، یا سایت شما نیاز به اشتراک گذاری احراز هویت کاربر در چندین دامنه یا زیر دامنه دارد، این احتمال وجود دارد که باید تغییراتی را در سایت خود ایجاد کنید. اطمینان از انتقال صاف به دور از کوکی های متقاطع سایت.

سفرهای مشترک کاربران

از لحاظ تاریخی، بسیاری از گردش‌های کاری هویت به کوکی‌های شخص ثالث متکی بودند. جدول برخی از سفرهای معمول کاربر و راه‌حل‌های بالقوه برای هر یک از این موارد را فهرست می‌کند که به کوکی‌های شخص ثالث وابسته نیستند. بخش های بعدی دلیل این توصیه ها را توضیح خواهند داد.

APIهای جایگزین توصیه شده برای موارد استفاده رایج

سفرهای کاربر مرتبط با هویت خود را آزمایش کنید

بهترین راه برای آزمایش اینکه آیا جریان ورود به سیستم شما تحت تأثیر تغییرات کوکی شخص ثالث قرار گرفته است یا خیر این است که از طریق ثبت نام، بازیابی رمز عبور، ورود به سیستم و جریان خروج از سیستم با فعال بودن پرچم تست کوکی شخص ثالث خود را انجام دهید.

این چک لیستی از مواردی است که وقتی کوکی های شخص ثالث را محدود کردید باید بررسی کنید:

• ثبت نام کاربر: ایجاد یک حساب کاربری جدید همانطور که انتظار می رود کار می کند. اگر از ارائه دهندگان هویت شخص ثالث استفاده می کنید، بررسی کنید که ثبت حساب های جدید برای هر یکپارچه سازی کار می کند.
• بازیابی رمز عبور: بازیابی رمز عبور همانطور که انتظار می رود کار می کند، از رابط کاربری وب گرفته تا CAPTCHA تا دریافت ایمیل بازیابی رمز عبور.
• ورود به سیستم: گردش کار ورود به سیستم در همان دامنه و هنگام پیمایش به دامنه های دیگر کار می کند. به یاد داشته باشید که هر ادغام ورود به سیستم را آزمایش کنید.
• خروج از سیستم: فرآیند خروج طبق انتظار عمل می کند و کاربر پس از جریان خروج از سیستم خارج می ماند.

همچنین باید آزمایش کنید که سایر ویژگی‌های سایت که نیاز به ورود کاربر به سیستم دارند، بدون کوکی‌های بین‌سایتی فعال باقی می‌مانند، به خصوص اگر شامل بارگیری منابع بین‌سایتی باشد. به عنوان مثال، اگر از CDN برای بارگیری تصاویر نمایه کاربر استفاده می‌کنید، مطمئن شوید که همچنان کار می‌کند. اگر سفرهای کاربر مهمی دارید، مانند تسویه‌حساب، که در یک ورود به سیستم هستند، مطمئن شوید که این سفرها به کار خود ادامه می‌دهند.

راه حل های ورود به سیستم

در این بخش، اطلاعات دقیق تری در مورد نحوه تأثیرگذاری آن جریان ها پیدا خواهید کرد.

ورود به سیستم یک شخص ثالث (SSO)

ورود به سیستم شخص ثالث (SSO) به کاربر این امکان را می‌دهد تا با یک مجموعه از اعتبارنامه‌ها در یک پلتفرم احراز هویت کند، سپس بدون نیاز به وارد کردن مجدد اطلاعات ورود به برنامه‌ها و وب‌سایت‌های متعدد، دسترسی داشته باشد. به دلیل پیچیدگی اجرای یک راه حل SSO، بسیاری از شرکت ها استفاده از یک ارائه دهنده راه حل شخص ثالث را برای به اشتراک گذاشتن وضعیت ورود به سیستم بین چندین منبع انتخاب می کنند. نمونه هایی از ارائه دهندگان عبارتند از Okta، Ping Identity، Google Cloud IAM یا Microsoft Entra ID.

اگر راه حل شما به یک ارائه دهنده شخص ثالث متکی است، ممکن است برخی تغییرات جزئی، مانند ارتقاء کتابخانه، ضروری باشد. بهترین رویکرد این است که از ارائه‌دهنده راهنمایی بجویید که چگونه وابستگی‌های کوکی شخص ثالث بر راه‌حل تأثیر می‌گذارد و چه رویکردی را برای خدمات خود توصیه می‌کند. برخی از ارائه‌دهندگان بی‌صدا از کوکی‌های شخص ثالث خارج می‌شوند، در این صورت، طرف‌های متکی به آن نیازی به به‌روزرسانی ندارند.

دامنه های متعدد

برخی از وب‌سایت‌ها از دامنه متفاوتی فقط برای احراز هویت کاربرانی استفاده می‌کنند که واجد شرایط کوکی‌های همان سایت نیستند، مانند وب‌سایتی که از example.com برای سایت اصلی و login.example برای جریان ورود استفاده می‌کند، که ممکن است نیاز به دسترسی به کوکی‌های شخص ثالث داشته باشد. اطمینان حاصل کنید که کاربر در هر دو دامنه احراز هویت شده است.

برخی از کسب و کارها می توانند چندین محصول را در دامنه ها یا زیر دامنه های مختلف میزبانی کنند. چنین راه حل هایی ممکن است بخواهند جلسه کاربر را در بین آن محصولات به اشتراک بگذارند، سناریویی که ممکن است نیاز به دسترسی به کوکی های شخص ثالث بین چندین دامنه داشته باشد.

مسیرهای مهاجرت احتمالی برای این سناریو عبارتند از:

• به‌روزرسانی برای استفاده از کوکی‌های شخص اول ("همان سایت") : تغییر زیرساخت وب‌سایت به گونه‌ای که جریان ورود به سیستم در همان دامنه (یا یک زیر دامنه) به عنوان سایت اصلی میزبانی شود، که فقط از کوکی‌های شخص اول استفاده می‌کند. این ممکن است به تلاش بیشتری نیاز داشته باشد، بسته به اینکه زیرساخت چگونه تنظیم شده است.
• استفاده از مجموعه‌های وب‌سایت مرتبط (RWS) و API دسترسی به فضای ذخیره‌سازی (SAA) : RWS دسترسی محدود به کوکی بین‌سایتی را بین گروه کوچکی از دامنه‌های مرتبط فعال می‌کند. با RWS، هنگام درخواست دسترسی به فضای ذخیره‌سازی با Storage Access API نیازی به درخواست کاربر نیست. این به SSO در آن دسته از RP هایی که در همان RWS IdP هستند اجازه می دهد. با این حال، RWS فقط از دسترسی به کوکی بین سایتی در تعداد محدودی دامنه پشتیبانی می کند.
• استفاده از Web Authentication API : Web Authentication API به اشخاص متکی (RPs) اجازه می دهد تا مجموعه محدودی از مبداهای مرتبط را ثبت کنند که در آن اعتبارنامه ها می توانند ایجاد و استفاده شوند.
• اگر در حال احراز هویت کاربران در بیش از 5 دامنه مرتبط هستید، مدیریت اعتبارنامه فدرال (FedCM) را کاوش کنید: FedCM به ارائه‌دهندگان هویت امکان می‌دهد بدون نیاز به کوکی‌های شخص ثالث، به Chrome تکیه کنند تا جریان‌های مرتبط با هویت را مدیریت کنند. در مورد شما، "دامنه ورود به سیستم" شما می تواند به عنوان ارائه دهنده هویت FedCM عمل کند و برای احراز هویت کاربران در سایر دامنه های شما استفاده شود.

احراز هویت از جاسازی ها

فرض کنید یک iframe 3-party-app.example در top-level.example تعبیه شده است. در 3-party-app.example ، کاربر می تواند با اعتبارنامه 3-party-app.example یا با ارائه دهنده شخص ثالث دیگری وارد سیستم شود.

کاربر روی «login» کلیک می‌کند و در پاپ‌آپ 3-party-app.example احراز هویت می‌کند. پاپ آپ 3-party-app.example یک کوکی شخص اول را تنظیم می کند. با این حال، iframe 3-party-app.example تعبیه شده در top-level.example پارتیشن بندی شده است و نمی تواند به مجموعه کوکی در زمینه شخص اول در 3-party-app.example دسترسی داشته باشد.

هنگامی که کاربر از top-level.example به 3-party-app.example هدایت شود و به عقب برگردد، همین مشکل رخ می دهد. کوکی در زمینه شخص اول سایت 3-party-app.example نوشته شده است، اما پارتیشن بندی شده است و در iframe 3-party-app.example قابل دسترسی نیست.

در مواردی که کاربر از مبدا جاسازی شده در زمینه سطح بالا بازدید کرده است، Storage Access API راه حل خوبی است.

برای دور شدن از راه‌حل‌هایی که به کوکی‌های شخص ثالث متکی هستند، توصیه می‌کنیم که ارائه‌دهندگان هویت از FedCM API استفاده کنند و FedCM از درون جاسازی‌ها به جای پنجره‌های بازشو فراخوانی شود.

راه حل پیشنهادی دیگری برای این جریان، Partitioned Popins ، در حال اجراست.

ورود به سیستم اجتماعی

دکمه‌های ورود به سیستم مانند ورود با Google ، ورود فیس‌بوک و ورود با توییتر نشانه قطعی این است که وب‌سایت شما از یک ارائه‌دهنده هویت فدرال استفاده می‌کند. هر ارائه دهنده هویت فدرال پیاده سازی خاص خود را خواهد داشت.

اگر از کتابخانه پلتفرم جاوا اسکریپت Google Sign-In منسوخ استفاده می‌کنید، می‌توانید اطلاعاتی درباره نحوه مهاجرت به کتابخانه جدیدتر Google Identity Services برای احراز هویت و مجوز پیدا کنید.

اکثر سایت‌هایی که از کتابخانه سرویس‌های هویت جدید Google استفاده می‌کنند، اتکا به کوکی‌های شخص ثالث را حذف کرده‌اند، زیرا کتابخانه بی‌صدا به استفاده از FedCM برای سازگاری منتقل می‌شود. توصیه می‌کنیم سایت خود را با فعال بودن پرچم آزمایش حذف مرحله کوکی شخص ثالث آزمایش کنید و در صورت نیاز از چک لیست مهاجرت FedCM برای آماده‌سازی استفاده کنید.

دسترسی و اصلاح داده های کاربر از جاسازی ها

محتوای جاسازی شده اغلب برای سفرهای کاربر مانند دسترسی یا مدیریت داده‌های مشخصات کاربر یا اشتراک‌ها استفاده می‌شود.

برای مثال، یک کاربر ممکن است وارد website.example شود که ویجت subscriptions.example را تعبیه می کند. این ویجت به کاربران اجازه می دهد تا داده های خود را مدیریت کنند، مانند اشتراک در محتوای ممتاز یا به روز رسانی اطلاعات صورتحساب. برای اصلاح داده‌های کاربر، ویجت جاسازی‌شده ممکن است نیاز به دسترسی به کوکی‌های خود در حین جاسازی در website.example داشته باشد. در سناریویی که این داده‌ها باید به website.example جدا شوند، CHIPS می‌تواند به اطمینان حاصل شود که embed می‌تواند به اطلاعات مورد نیاز خود دسترسی پیدا کند. با CHIPS، ویجت subscriptions.example تعبیه شده در website.example به داده های اشتراک کاربر در سایر وب سایت ها دسترسی نخواهد داشت.

مورد دیگری را در نظر بگیرید: ویدیویی از streaming.example در website.example جاسازی شده است و کاربر اشتراک streaming.example ممتاز دارد که ویجت برای غیرفعال کردن تبلیغات باید از آن مطلع باشد. اگر نیاز به دسترسی به کوکی مشابه در چندین سایت وجود دارد، اگر کاربر قبلاً از streaming.example به عنوان سطح بالا بازدید کرده است، از Storage Access API استفاده کنید و اگر مجموعه website.example مالک streaming.example باشد، از مجموعه‌های وب‌سایت مرتبط استفاده کنید.

از Chrome 131، FedCM با Storage Access API یکپارچه شده است. با این ادغام، زمانی که کاربر درخواست FedCM را می‌پذیرد، مرورگر به IdP دسترسی تعبیه‌شده به فضای ذخیره‌سازی پارتیشن نشده را می‌دهد.

برای اطلاعات بیشتر در مورد اینکه کدام API را برای مدیریت یک سفر کاربر خاص با محتوای جاسازی شده انتخاب کنید، راهنمای جاسازی ها را بررسی کنید.

خروج از کانال جلو

خروج از کانال جلو مکانیزمی است که به کاربر اجازه می‌دهد تا زمانی که کاربر از یک سرویس خارج می‌شود، از همه برنامه‌های مرتبط خارج شود. خروج از کانال جلوی OIDC به IdP نیاز دارد که چندین iframe حزب متکی (RP) را که به کوکی‌های RP متکی هستند تعبیه کند.

اگر راه حل شما به یک ارائه دهنده هویت متکی است، ممکن است تغییرات جزئی (مانند ارتقاء کتابخانه) مورد نیاز باشد. برای راهنمایی بیشتر، با ارائه دهنده هویت خود تماس بگیرید.

برای رسیدگی به این مورد استفاده، FedCM با ویژگی logoutRPs آزمایش کرد. این به IdP اجازه می‌دهد تا از هر RP که کاربر قبلاً ارتباط RP-IdP را تأیید کرده است، خارج شود. این ویژگی دیگر در دسترس نیست، اما توصیه می کنیم اگر به این ویژگی علاقه دارید یا به آن نیاز دارید، به پیشنهاد اولیه نگاهی بیندازید و نظرات خود را با ما در میان بگذارید.

سایر سفرهای کاربر

سفرهای کاربر که به کوکی‌های شخص ثالث متکی نیستند، نباید تحت تأثیر تغییرات در نحوه مدیریت Chrome با کوکی‌های شخص ثالث قرار گیرند. راه‌حل‌های موجود، مانند ورود به سیستم، خروج از سیستم، یا بازیابی حساب در زمینه شخص اول، 2FA، باید طبق برنامه عمل کنند. نقاط بالقوه شکست قبلا توضیح داده شده است. برای اطلاعات بیشتر در مورد یک API خاص، صفحه وضعیت API را بررسی کنید. هرگونه شکستگی را به goo.gle/report-3pc-broken گزارش دهید. همچنین می‌توانید یک فرم بازخورد ارسال کنید یا مشکلی را در GitHub در مخزن پشتیبانی توسعه‌دهنده Privacy Sandbox ثبت کنید.

سایت خود را حسابرسی کنید

اگر وب‌سایت شما یکی از سفرهای کاربر توضیح داده شده در این راهنما را اجرا می‌کند، باید مطمئن شوید که سایت‌های شما آماده هستند : سایت خود را برای استفاده از کوکی شخص ثالث بررسی کنید، آزمایش شکستگی و انتقال به راه‌حل‌های پیشنهادی.