يقدّم Chrome تجربة جديدة تتيح للمستخدم اختيار ملفات تعريف الارتباط التابعة لجهات خارجية. عليك تجهيز موقعك الإلكتروني للمستخدمين الذين يختارون التصفّح بدون ملفات تعريف الارتباط التابعة لجهات خارجية.
في هذه الصفحة، ستجد معلومات عن سيناريوهات الهوية التي يُرجّح أن تتعرّض للتأثّر، بالإضافة إلى إشارات إلى الحلول المحتملة.
إذا كان موقعك الإلكتروني يعالج عمليات تسجيل الدخول ضمن النطاق والنطاقات الفرعية نفسها، مثل
publisher.example
وlogin.publisher.example
، لن يستخدم ملفات تعريف الارتباط على جميع المواقع
، ومن المتوقّع ألا تتأثّر عملية تسجيل الدخول بتغييرات ملفات تعريف الارتباط التابعة لجهات خارجية.
ومع ذلك، إذا كان موقعك الإلكتروني يستخدم نطاقًا منفصلاً لتسجيل الدخول، مثل استخدام تسجيل الدخول باستخدام حساب Google أو تسجيل الدخول باستخدام حساب Facebook، أو إذا كان موقعك الإلكتروني يحتاج إلى مشاركة مصادقة المستخدِم على مستوى نطاقات أو نطاقات فرعية متعددة، من المحتمل أن تحتاج إلى إجراء تغييرات على موقعك الإلكتروني لضمان الانتقال بسلاسة من استخدام ملفّات تعريف الارتباط على جميع المواقع الإلكترونية.
رحلات المستخدم الشائعة
في السابق، كان العديد من مهام سير عمل الهوية يعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية. يسرد الجدول بعض تجارب المستخدِمين الشائعة والحلول المحتملة لكلٍّ من هذه التجارب التي لا تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية. توضّح الأقسام التالية أسباب هذه الاقتراحات.
واجهات برمجة التطبيقات البديلة المقترَحة لحالات الاستخدام الشائعة
رحلة المستخدِم | واجهات برمجة التطبيقات المقترَحة |
---|---|
تسجيل الدخول إلى وسائل التواصل الاجتماعي |
بالنسبة إلى موفِّري الهوية: تنفيذ FedCM بالنسبة إلى الأطراف المعتَمَدة: يُرجى التواصل مع موفِّر الهوية. |
تسجيل الخروج من القناة الأمامية | بالنسبة إلى موفّري الهوية: تنفيذ FedCM |
بالنسبة إلى موفّري الهوية أو الحلول المخصّصة: مجموعات المواقع الإلكترونية ذات الصلة |
|
إدارة الملف الشخصي للمستخدم |
Storage Access API Related Website Sets CHIPS FedCM |
Storage Access API Related Website Sets CHIPS FedCM |
|
المصادقة |
Storage Access API FedCM Web Authentication API scienceالنوافذ المقسَّمة |
لا تعتمد هذه السيناريوهات بشكل عام على ملفات تعريف الارتباط التابعة لجهات خارجية، ولا يُتوقّع أن تتأثّر بها. |
اختبار تجارب المستخدمين المتعلّقة بالهوية
إنّ أفضل طريقة لاختبار ما إذا كان مسار تسجيل الدخول يتأثّر بتغييرات ملفات تعريف الارتباط التابعة لجهات خارجية هي مراجعة مسارات التسجيل واسترداد كلمة المرور وتسجيل الدخول وتسجيل الخروج مع تفعيل علامة اختبار ملفات تعريف الارتباط التابعة لجهات خارجية.
في ما يلي قائمة تحقّق بالإجراءات التي يجب اتّخاذها بعد حظر ملفّات تعريف الارتباط التابعة لجهات خارجية:
- تسجيل المستخدمين: يعمل إنشاء حساب جديد على النحو المتوقّع. في حال استخدام موفّري هوية تابعين لجهات خارجية، تأكَّد من أنّ تسجيل الحسابات الجديدة يعمل في كل عملية دمج.
- استرداد كلمة المرور: تعمل ميزة استرداد كلمة المرور على النحو المتوقّع، بدءًا من واجهة مستخدِم الويب، ومرورًا بـ رموز CAPTCHA، ووصولاً إلى تلقّي الرسالة الإلكترونية لاسترداد كلمة المرور.
- تسجيل الدخول: يعمل سير عمل تسجيل الدخول داخل النطاق نفسه وعند الانتقال إلى نطاقات أخرى. تذكَّر اختبار كل عملية دمج لتسجيل الدخول.
- تسجيل الخروج: تتم عملية تسجيل الخروج على النحو المتوقع، ويظل المستخدم مسجِّلاً الخروج بعد هذا الإجراء.
عليك أيضًا اختبار أنّ ميزات الموقع الإلكتروني الأخرى التي تتطلب تسجيل دخول المستخدم تظلّ صالحة بدون استخدام ملفات تعريف الارتباط على مواقع إلكترونية متعددة، خاصةً إذا كانت تتضمّن تحميل موارد من مواقع إلكترونية متعددة. على سبيل المثال، إذا كنت تستخدم شبكة توصيل للمحتوى (CDN) لتحميل صور الملف الشخصي للمستخدم، تأكَّد من أنّ ذلك لا يزال يعمل. إذا كانت لديك رحلات مستخدِمين مهمّة، مثل رحلة الدفع التي تتطلّب تسجيل الدخول، تأكَّد من أنّها لا تزال تعمل.
حلول تسجيل الدخول
في هذا القسم، ستجد معلومات أكثر تحديدًا حول كيفية تأثّر هذه العمليات.
الدخول المُوحَّد (SSO) التابع لجهة خارجية
تتيح خدمة الدخول المُوحَّد (SSO) التابعة لجهة خارجية للمستخدم المصادقة باستخدام مجموعة واحدة من بيانات الاعتماد على منصة واحدة، ثم الوصول إلى تطبيقات ومواقع إلكترونية متعدّدة بدون الحاجة إلى إعادة إدخال معلومات تسجيل الدخول. بسبب تعقيد تنفيذ حلّ الدخول المُوحَّد، تختار العديد من الشركات استخدام مقدّم حلّ تابع لجهة خارجية لمشاركة حالة تسجيل الدخول بين مصادر متعدّدة. تشمل أمثلة مقدّمي الخدمة Okta أو Ping Identity أو Google Cloud IAM أو Microsoft Entra ID.
إذا كان الحلّ يعتمد على مقدّم خدمة تابع لجهة خارجية، قد يكون من الضروري إجراء بعض التغييرات البسيطة، مثل ترقية المكتبة. وأفضل طريقة هي طلب الإرشادات من مقدّم الخدمة حول كيفية تأثير اعتماديات ملفات تعريف الارتباط التابعة لجهات خارجية على الحلّ والطريقة التي يقترحها مزوّد الخدمة. سيتوقف بعض مزوّدي الخدمات عن استخدام ملفات تعريف الارتباط التابعة لجهات خارجية بدون إشعار، وفي هذه الحالة لن تحتاج الجهات المشارِكة إلى إجراء أي تعديلات.
نطاقات متعددة
تستخدم بعض المواقع الإلكترونية نطاقًا مختلفًا فقط لمصادقة المستخدمين غير المؤهلين لملفات تعريف الارتباط الخاصة بالموقع الإلكتروني نفسه، مثل موقع إلكتروني يستخدم example.com
للموقع الإلكتروني الرئيسي وlogin.example
لمسار تسجيل الدخول، ما قد يتطلب الوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية لضمان مصادقة المستخدم في كلا النطاقين.
يمكن أن تملك بعض الأنشطة التجارية منتجات متعددة مستضافة على نطاقات أو نطاقات فرعية مختلفة. قد تحتاج هذه الحلول إلى مشاركة جلسة المستخدِم على مستوى هذه المنتجات، وهو سيناريو قد يتطلّب الوصول إلى ملفات تعريف الارتباط التابعة لجهات خارجية بين نطاقات متعددة.
مسارات النقل المحتملة لهذا السيناريو هي:
- التحديث لاستخدام ملفات تعريف الارتباط للطرف الأول ("الملفات على الموقع نفسه"): تغيير البنية الأساسية للموقع الإلكتروني لكي يتم استضافة عملية تسجيل الدخول على النطاق نفسه (أو نطاق فرعي) للموقع الإلكتروني الرئيسي، والذي سيستخدم ملفات تعريف الارتباط للطرف الأول فقط. قد يتطلّب ذلك بذل جهد أكبر، استنادًا إلى طريقة إعداد البنية الأساسية.
- استخدام مجموعات المواقع الإلكترونية ذات الصلة (RWS) وStorage Access API (SAA): تتيح مجموعات المواقع الإلكترونية ذات الصلة إمكانية وصول محدودة إلى ملفات تعريف الارتباط على مستوى المواقع الإلكترونية بين مجموعة صغيرة من النطاقات ذات الصلة. باستخدام RWS، ما مِن حاجة إلى طلب من المستخدم عند طلب الوصول إلى مساحة التخزين باستخدام واجهة برمجة التطبيقات Storage Access. يتيح ذلك الدخول المُوحَّد في خدمات الربط هذه التي تقع في نظام RWS نفسه الذي يقع فيه موفِّر الهوية. ومع ذلك، لا تتيح RWS الوصول إلى ملفات تعريف الارتباط على مواقع إلكترونية متعددة إلا على مستوى عدد محدود من النطاقات.
- استخدام Web Authentication API: تسمح Web Authentication API للأطراف الموثوق بها (RP) بتسجيل مجموعة محدودة من المصادر ذات الصلة التي يمكن إنشاء بيانات الاعتماد واستخدامها فيها.
- إذا كنت تُجري مصادقة للمستخدمين على أكثر من 5 نطاقات مرتبطة، يمكنك استكشاف إدارة بيانات الاعتماد المُدمجة (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
.
وتحدث المشكلة نفسها عند إعادة توجيه المستخدم من top-level.example
إلى 3-party-app.example
ثم الرجوع إليه. يتمّ كتابة ملفّ تعريف الارتباط في سياق الطرف الأوّل لموقع 3-party-app.example
الإلكتروني، ولكنّه مُقسَّم ولا يمكن الوصول إليه ضمن إطار iframe في 3-party-app.example
.
في الحالات التي يزور فيها المستخدم المصدر المضمّن في سياق أعلى مستوى، تكون Storage Access API حلاً جيدًا.
للتوقف عن استخدام الحلول التي تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية، ننصحك بأن يتبنّى موفّرو الهوية FedCM API وأن يتمّ استدعاء FedCM من داخل عمليات التضمين بدلاً من النوافذ المنبثقة.
يتم حاليًا تنفيذ حلّ آخر مقترَح لهذه العملية، وهو النوافذ المنبثقة المقسّمة.
تسجيل الدخول باستخدام حساب على وسائل التواصل الاجتماعي
إنّ أزرار تسجيل الدخول، مثل تسجيل الدخول باستخدام حساب Google وتسجيل الدخول إلى Facebook وتسجيل الدخول باستخدام حساب Twitter هي علامة واضحة على أنّ موقعك الإلكتروني يستخدم موفِّر هوية موحّدة. سيكون لكل موفِّر هوية موحّد تطبيق خاص به.
إذا كنت تستخدم مكتبة منصة JavaScript لتسجيل الدخول بحساب Google المتوقّفة نهائيًا، يمكنك العثور على معلومات حول كيفية نقل البيانات إلى مكتبة "خدمات هوية Google" الأحدث من أجل المصادقة والتفويض.
أزالت معظم المواقع الإلكترونية التي تستخدم مكتبة 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
من الفئة المميّزة، ويجب أن تعرف الأداة ذلك لإيقاف عرض الإعلانات. إذا كان ملف تعريف الارتباط نفسه بحاجة إلى الوصول إلى مواقع إلكترونية متعددة، ننصحك باستخدام Storage Access API إذا سبق للمستخدم زيارة streaming.example
كمستوى أعلى ومجموعات المواقع الإلكترونية ذات الصلة إذا كانت مجموعة website.example
تمتلك streaming.example
.
اعتبارًا من الإصدار 131 من Chrome، تم دمج FedCM مع Storage Access API. من خلال هذا الدمج، عندما يقبل المستخدم طلب FedCM، سيمنح المتصفّح موفِّر الهوية إذن الوصول إلى مساحة التخزين غير المقسّمة.
لمزيد من المعلومات حول واجهة برمجة التطبيقات التي يجب اختيارها للتعامل مع رحلة مستخدم معيّنة تتضمّن محتوى مضمّنًا، يُرجى الاطّلاع على دليل عمليات التضمين.
تسجيل الخروج من القناة الأمامية
تسجيل الخروج من قناة العرض الأمامية هو آلية تسمح للمستخدم بتسجيل الخروج من جميع التطبيقات ذات الصلة عند تسجيل الخروج من خدمة واحدة. تتطلّب عملية تسجيل الخروج من خلال قناة العرض الأمامية في إطار عمل OIDC أن تضمّن خدمة إدارة الهوية العديد من إطارات iframe الخاصة بالطرف الموثوق به (RP) التي تعتمد على ملفات تعريف الارتباط الخاصة بالطرف الموثوق به.
إذا كان الحلّ يعتمد على مزوّد هوية، قد تكون هناك حاجة إلى إجراء تغييرات بسيطة (مثل ترقية المكتبة). للحصول على مزيد من الإرشادات، يمكنك التواصل مع موفِّر الهوية.
لمعالجة حالة الاستخدام هذه، جرّب FedCM استخدام ميزة logoutRPs
. سمح ذلك لموفِّر الهوية بتسجيل خروج أي مقدّم خدمات اعتماد وافق المستخدم سابقًا على تواصله مع موفِّر الهوية. لم تعد هذه الميزة متوفرة، ولكن ننصحك بإلقاء نظرة على العرض الأولي ومشاركة ملاحظاتك معنا إذا كنت مهتمًا بها أو كنت بحاجة إليها.
تجارب المستخدمين الأخرى
من المفترض ألا تتأثر رحلات المستخدِمين التي لا تعتمد على ملفات تعريف الارتباط التابعة لجهات خارجية بالتغييرات في طريقة معالجة Chrome لملفات تعريف الارتباط التابعة لجهات خارجية. من المفترض أن تعمل الحلول الحالية على النحو المطلوب، مثل تسجيل الدخول أو تسجيل الخروج أو استرداد الحساب في سياق الجهة الأولى، وميزة "التحقّق من الهوية ثنائية العوامل". سبق أن تم توضيح نقاط التعطّل المحتملة. للاطّلاع على مزيد من المعلومات حول واجهة برمجة تطبيقات معيّنة، يُرجى الانتقال إلى صفحة حالة واجهة برمجة التطبيقات. يُرجى الإبلاغ عن أي مشاكل في goo.gle/report-3pc-broken. يمكنك أيضًا إرسال نموذج ملاحظات أو الإبلاغ عن مشكلة على GitHub في مستودع دعم المطوّرين في مبادرة "حماية الخصوصية".
تدقيق موقعك الإلكتروني
إذا كان موقعك الإلكتروني ينفِّذ إحدى تجارب المستخدِمين الموضّحة في هذا الدليل، عليك التأكّد من استعداد مواقعك الإلكترونية: تحقّق من موقعك الإلكتروني بحثًا عن استخدام ملفات تعريف الارتباط التابعة لجهات خارجية، واختَبِر حدوث أي أعطال، وانتقِل إلى الحلول المقترَحة.