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

کوکی‌های شخص ثالث ممکن است توسط محدودیت‌های مرورگر، تنظیمات کاربر ، پرچم‌های توسعه‌دهنده یا سیاست‌های سازمانی مسدود شوند.

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

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

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

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

مسیرهای رایج کاربران

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

موارد موجود در جدول در مراحل اولیه توسعه خود هستند. بازخورد شما ارزشمند است و به شکل‌گیری آینده آنها کمک خواهد کرد. نظرات خود را در مورد این APIها ارائه دهید: Popins Partitioned .

سفر کاربر API های پیشنهادی
ورود به سیستم از طریق شبکه‌های اجتماعی برای ارائه دهندگان هویت: پیاده سازی FedCM
برای طرف‌های متکی: با ارائه‌دهنده‌ی هویت خود تماس بگیرید

ورود به سیستم تکی

برای ارائه دهندگان هویت یا راهکارهای سفارشی: مجموعه وب‌سایت‌های مرتبط

مدیریت پروفایل کاربر API دسترسی به فضای ذخیره‌سازی
مجموعه وب‌سایت‌های مرتبط
چیپس
FedCM + SAA

مدیریت اشتراک‌ها

API دسترسی به فضای ذخیره‌سازی
مجموعه وب‌سایت‌های مرتبط
چیپس
FedCM + SAA
احراز هویت API دسترسی به فضای ذخیره‌سازی
FedCM
API احراز هویت وب
پاپین‌های تقسیم‌شده

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

این سناریوها عموماً وابستگی به کوکی‌های شخص ثالث ندارند و انتظار نمی‌رود که تحت تأثیر قرار گیرند.

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

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

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

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

راهکارهای ورود به سیستم

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

ورود یکپارچه شخص ثالث (SSO)

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

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

دامنه‌های چندگانه

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

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

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

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

احراز هویت از طریق جاسازی‌ها

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

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

تصویری از جریان احراز هویت با یک پنجره بازشو بین یک وب‌سایت RP و یک IdP شخص ثالث، زمانی که کوکی‌های شخص ثالث محدود شده‌اند.
جریان احراز هویت با پنجره‌های بازشو: وقتی کوکی‌های شخص ثالث محدود می‌شوند، یک iframe IdP شخص ثالث که در یک RP تعبیه شده است، نمی‌تواند به کوکی‌های خود دسترسی داشته باشد.

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

تصویری از جریان احراز هویت با تغییر مسیرها بین یک وب‌سایت RP و یک IdP شخص ثالث، زمانی که کوکی‌های شخص ثالث محدود شده‌اند.
جریان احراز هویت با تغییر مسیرها: وقتی کوکی‌های شخص ثالث محدود می‌شوند، کوکی در چارچوب دامنه سطح بالا نوشته می‌شود و از طریق iframe قابل دسترسی نیست.

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

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

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

ورود از طریق شبکه‌های اجتماعی

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

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

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

دسترسی و تغییر داده‌های کاربر از طریق جاسازی‌ها

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

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

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

از کروم ۱۳۱، FedCM با رابط برنامه‌نویسی کاربردی دسترسی به حافظه (Storage Access API) یکپارچه شده است. با این یکپارچه‌سازی، وقتی کاربر درخواست FedCM را می‌پذیرد، مرورگر به IdP embed دسترسی به حافظه پارتیشن‌بندی نشده را اعطا می‌کند.

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

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

سفرهای کاربری که به کوکی‌های شخص ثالث متکی نیستند، نباید تحت تأثیر تغییرات در نحوه مدیریت کوکی‌های شخص ثالث توسط کروم قرار گیرند. راه‌حل‌های موجود، مانند ورود، خروج یا بازیابی حساب کاربری در چارچوب شخص ثالث، 2FA، باید طبق برنامه کار کنند. نقاط احتمالی خرابی قبلاً شرح داده شده‌اند. برای اطلاعات بیشتر در مورد یک API خاص، صفحه وضعیت API را بررسی کنید.

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

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