تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

تجربة بروتوكول تأكيد عنوان البريد الإلكتروني من خلال تجربة أصل

Rowan Merewood

تاريخ النشر: 8 يوليو 2026، تاريخ آخر تعديل: 5 أكتوبر 2026

عند جمع عنوان بريد إلكتروني كجزء من عملية الاشتراك أو تسجيل الدخول أو الاشتراك أو الدفع أو استرداد الحساب أو أي عملية أخرى، من الممارسات الشائعة تأكيد أنّ عنوان البريد الإلكتروني يملكه الشخص الذي أدخله. تتطلّب طرق إثبات الملكية الحالية، مثل كلمات المرور الصالحة لمرة واحدة أو روابط تأكيد عنوان البريد الإلكتروني (الروابط السحرية)، أن ينتقل المستخدم إلى مكان آخر غير موقعك الإلكتروني. يمكن أن تؤدي هذه العملية المزعجة إلى زيادة خطر تخلّي المستخدم، سواء كان شخصًا أو برنامجًا، عن الجلسة بالكامل وعدم إكمال عملية المصادقة.

واجهة برمجة التطبيقات Email Verification API هي اقتراح يتيح للمتصفّح التواصل مباشرةً مع مزوّد خدمة البريد الإلكتروني للتأكّد من أنّ المستخدم يملك عنوان البريد الإلكتروني. يختار المستخدمون عنوان بريد إلكتروني من اقتراح الملء التلقائي أو الإكمال التلقائي في المتصفّح، ويرسلون النموذج، ويتأكّد الموقع الإلكتروني من عنوان البريد الإلكتروني لدى مقدّم الخدمة بدون إرسال رسالة إلكترونية أو مقاطعة تجربة المستخدم.

عرض توضيحي لطلب المستخدم في Email Verification API

يُعدّ جمع عناوين البريد الإلكتروني نقطة إحالة ناجحة مهمة في رحلة المستخدم، ويريد Chrome تلقّي ملاحظات حول الاقتراح من المواقع الإلكترونية التي تريد إثبات ملكية عناوين البريد الإلكتروني، ومقدّمي خدمات البريد الإلكتروني الذين يمكنهم إجراء عملية إثبات الملكية، والمستخدمين الذين يجرّبون هذه العملية. يمكنك الاشتراك في مرحلة التجربة والتقييم اليوم واتّباع تعليمات التنفيذ هنا. للحصول على معلومات عامة حول إعدادات مرحلة التجربة والتقييم، يُرجى الرجوع إلى البدء في استخدام مرحلة التجربة والتقييم.

يمكنك تجربة المسار باستخدام حساب تجريبي:

تمنحك النسخة التجريبية الخاصة بالجهة المصدرة حسابًا وجلسة وهميَّين للبريد الإلكتروني
يمكن للتطبيق التجريبي الخاص بأداة التحقّق التحقّق من أي موفّر خدمة مشارك.

عملية تأكيد عنوان البريد الإلكتروني

توضّح الأقسام التالية ما تحتاج إليه أنت والمستخدمون لبدء عملية إثبات ملكية عنوان البريد الإلكتروني، كما توضّح سير العمل الكامل عند استخدام بروتوكول إثبات ملكية عنوان البريد الإلكتروني.

العبارات الرئيسية

في ما يلي المصطلحات الأساسية لواجهة برمجة التطبيقات Email Verification API:

الجهة التي تتحقّق من صحة عنوان البريد الإلكتروني: هي الموقع الإلكتروني الذي يجمع عنوان البريد الإلكتروني ويريد التحقّق من صحته. يُطلق على الجهة التي تتحقّق من الهوية أيضًا اسم الطرف المعتمِد.
مقدّم خدمة البريد الإلكتروني: الخدمة التي توفّر عنوان البريد الإلكتروني للمستخدم، مثل gmail.com.
الجهة المصدرة: هي الخدمة التي تدير الحساب الخاص بالبريد الإلكتروني للمستخدم، مثل accounts.google.com. يُطلق على جهة الإصدار أيضًا اسم موفِّر الهوية.

في بعض الحالات، قد يعمل مزوّد خدمة البريد الإلكتروني والجهة المصدرة من النطاق نفسه. ومع ذلك، من المهم التمييز بين امتلاك عنوان بريد إلكتروني والحصول على جلسة نشطة للحساب المرتبط.

بنية عملية التحقّق من عنوان البريد الإلكتروني — بنية خطوات إثبات ملكية عنوان البريد الإلكتروني

المتطلبات الأساسية

يجب أن يكون المستخدم مسجّلاً الدخول إلى مقدّم خدمة البريد الإلكتروني أو جهة الإصدار في ملف المتصفّح نفسه. على سبيل المثال، إذا كان يستخدم Gmail، يجب أن يكون مسجّلاً الدخول إلى حساب Google.
بصفتك موقعًا إلكترونيًا مشاركًا في عملية التحقّق، عليك الاشتراك في مرحلة التجربة والتقييم وتقديم الرمز المميّز على الصفحة نفسها التي تتضمّن نموذج البريد الإلكتروني.
على المستخدم اختيار عنوان بريده الإلكتروني من القائمة المنسدلة الخاصة بالملء التلقائي أو الإكمال التلقائي.
- إذا سبق للمستخدم إدخال عنوان بريد إلكتروني في الحقل، سيتم اقتراحه باستخدام ميزة "الإكمال التلقائي".
- إذا أضاف المستخدم عنوان بريده الإلكتروني باستخدام إعدادات Chrome ضمن "الملء التلقائي وكلمة المرور" (chrome://settings/autofill)، سيتم اقتراحه باستخدام ميزة "الملء التلقائي".
  
  ملاحظة: من المقرّر أن يتيح إصدار مستقبلي إدخال العناوين يدويًا. (تعديل: متاح اعتبارًا من الإصدار 151 من Chrome)
في المرة الأولى التي يقدّم فيها المستخدم عنوان بريد إلكتروني لإثبات ملكيته، سيظهر له طلب للحصول على إذن. يحدث ذلك مرة واحدة فقط لكل عنوان بريد إلكتروني.

بعد أن يسجّل المستخدم جلسة نشطة في المتصفّح، يمكنه بدء العملية باتّباع الخطوات التالية:

في نموذج يتضمّن حقل بريد إلكتروني، يختار المستخدم عنوان بريده الإلكتروني من القائمة المنسدلة الخاصة بالإكمال التلقائي. يوفّر الموقع الإلكتروني الذي يتحقّق من صحة الرمز المميز حقلاً مخفيًا في النموذج يتضمّن رقمًا خاصًا لكل آلة افتراضية للتحقّق من صحة هذا الطلب.
سيسترد المتصفّح بعد ذلك سجلّ نظام أسماء النطاقات الخاص بتأكيد عنوان البريد الإلكتروني لنطاق البريد الإلكتروني. يشير ذلك إلى جهة إصدار الشهادة. سيؤكّد جهة الإصدار بعد ذلك أنّ لديها جلسة نشطة لعنوان البريد الإلكتروني هذا.

ملاحظة: لا تكشف هذه الطلبات عن أي معلومات إضافية حول المستخدم. لا يتلقّى الموقع الإلكتروني الذي يتم التحقّق منه أي معلومات خلال هذه الخطوة. لا يرى الجهة المصدرة سوى طلب التحقّق من أنّ المستخدم موجود، ولا ترى الموقع الإلكتروني الذي أرسل الطلب.
سيقدّم جهة الإصدار بعد ذلك رمز تأكيد البريد الإلكتروني (EVT) الخاص بالعنوان. يجمع المتصفّح ذلك في رمز JWT مرتبط بمفتاح مع EVT ومصدر الموقع الإلكتروني ورمز الاستخدام لمرة واحدة من نموذج الإدخال.
عند إرسال النموذج، تتم إضافة حزمة EVT إلى الحقل المخفي وإرسالها إلى الموقع الإلكتروني.
بعد ذلك، يتحقّق الموقع الإلكتروني من صحة كل من التفاصيل التالية: عنوان البريد الإلكتروني المتوقّع، والرقم العشوائي، والتواقيع من المتصفّح والجهة المصدرة.
يظهر للمستخدم إشعار صغير لإعلامه بأنّ مقدّم خدمة البريد الإلكتروني قد أثبت ملكية عنوانه.

توفّر هذه العملية للموقع الإلكتروني الذي يجري عملية التحقّق تأكيدًا بأنّ عنوان البريد الإلكتروني صالح ويخصّ المستخدم الحالي، ما يعني أنّه يمكن للموقع الإلكتروني تخطّي إرسال رسالة تأكيد إلكترونية.

يمكن للمستخدمين إدارة عناوين البريد الإلكتروني التي تم تأكيدها من خلال الانتقال إلى الإعدادات > الملء التلقائي وكلمات المرور > معلومات الاتصال > عنوان البريد الإلكتروني الذي تم تأكيده (أو فتح chrome://settings/contactInfo).

اعتبارات حالات الاستخدام

يُعدّ تأكيد عنوان البريد الإلكتروني تحسينًا تدريجيًا على مسار المستخدم الحالي، وهو يزيل حاجة المستخدم إلى مغادرة موقعك الإلكتروني لاسترداد كلمة مرور صالحة لمرة واحدة أو النقر على رابط. يمكن للمواقع الإلكترونية إضافة حقول تأكيد عنوان البريد الإلكتروني إلى جميع النماذج ذات الصلة، مثل عمليات تسجيل الدخول والاشتراك في النشرات الإخبارية وإنشاء الحسابات واسترداد كلمات المرور. لا يتم تفعيل EVP إلا إذا كان المتصفّح يتيح ذلك. في حال عدم تلقّي رمز عند إرسال الطلب أو تعذُّر إكمال أي من خطوات التحقّق، يمكنك الرجوع إلى عملية تأكيد عنوان البريد الإلكتروني التلقائية. يعني هذا أيضًا أنّه لا يمكن رصد الميزات لواجهة برمجة التطبيقات، فالموقع الإلكتروني للتحقّق يتعامل مع EVT على أنّه اختياري، ويعالجه إذا كان متوفّرًا في الطلب.

يؤكّد إثبات ملكية عنوان البريد الإلكتروني أنّ المستخدم لديه جلسة نشطة مع مقدّم خدمة عنوان البريد الإلكتروني. ولا يثبت هذا الإجراء أنّ رسالتك الإلكترونية قد وصلت إلى المستخدِم. قد تحتاج إلى إرسال رسائل إلكترونية ترحيبية أو رسائل إعداد حالية، وقد تحتاج إلى مطالبة المستخدم بالتحقّق من إعدادات الرسائل غير المرغوب فيها.

تنفيذ الموقع الإلكتروني الخاص بأداة التحقّق

للحصول على تفاصيل إضافية، يمكنك الاطّلاع على الرمز التجريبي الشامل والرجوع إلى خطوات التحقّق في اقتراحَي واجهة برمجة التطبيقات الخاصة بميزة "التحقّق من عنوان البريد الإلكتروني" وبروتوكول ميزة "التحقّق من عنوان البريد الإلكتروني".

ضبط حقول النموذج

تأكَّد من أنّ حقول النموذج تحتوي على السمات الصحيحة:

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

اضبط السمتَين type وautocomplete لعنصر الإدخال email على email للسماح للمتصفّح باقتراح إكمال تلقائي لعنوان البريد الإلكتروني.

سيتم ملء حقل hidden الجديد برمز التحقّق من عنوان البريد الإلكتروني عند إرسال النموذج. السمات الضرورية هي:

اضبط القيمة على type="hidden" لأنّ هذا الحقل لا يتطلّب بيانات أدخلها المستخدم.
اضبط nonce="rAnD0m-VaLuE". يجب أن يوفّر الموقع الإلكتروني قيمة فريدة صالحة لمرة واحدة مرتبطة بالجلسة من أجل التحقّق من عملية إرسال النموذج.
اضبط autocomplete="email-verification-token". يستخدم المتصفّح هذه السمة لتحديد الحقل الذي سيتم ملؤه.

تحقَّق من صحة عناصر النموذج من خلال مراجعة لوحة "الشبكة" في "أدوات مطوّري البرامج". عند اختيار عنوان بريد إلكتروني، سيؤدي ذلك إلى أن يفعّل المتصفّح نظام أسماء النطاقات (DNS) وعمليات البحث اللاحقة عن الحساب لدى موفّر البريد الإلكتروني والجهة المصدرة. هذه الطلبات داخلية في المتصفّح، ولا يتلقّى موقعك الإلكتروني أي شيء إلى أن يتم إرسال النموذج.

التحقّق من صحة EVT

هناك خمس خطوات للتحقّق من صحة كل مكوّن من حزمة EVT.

تحليل الرمز المميّز
التحقّق من صحة القيم المتوقّعة
التحقّق من صحة ربط المفتاح
التحقّق من صحة سجلّ نظام أسماء النطاقات
اكتشاف جهة الإصدار والتحقّق من توقيع EVT

1. تحليل الرمز المميّز

تحتوي البيانات الأولية من نموذج الإرسال على EVT والمطالبات الموقّعة في رمز مميّز خاص بالويب JSON للإفصاح الانتقائي (SD-JWT+KB) مفصولة بعلامة المدة (الحرف ~). عليك فصل هذه العناصر وفك ترميز عناوين وبيانات Javascript Object Signing and Encryption (JOSE) (على سبيل المثال، باستخدام jose في Node.js).

إذا تحقّق example.com من demo@gmail.com، ستبدو الحمولة التي تم فك تشفيرها مشابهة للمثال التالي:

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "demo@gmail.com",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. التحقّق من صحة القيم المتوقّعة

تأكَّد من أنّ القيم الأساسية في الحمولة تتطابق مع القيم التي قدّمتها:

تأكَّد من أنّ قيمة email_verified مضبوطة على true.
تأكَّد من أنّ email يتطابق مع عنوان البريد الإلكتروني المقدَّم في النموذج.
تأكَّد من أنّ قيمة nonce تتطابق مع الرقم الخاص المقدَّم في النموذج.
تأكَّد من أنّ aud يتطابق مع مصدر موقعك الإلكتروني.
تأكَّد من أنّ iat يتضمّن طابعًا زمنيًا حديثًا نسبيًا، مثلاً بعد عرض النموذج.

3- التحقّق من صحة ربط المفاتيح

ينشئ المتصفّح مفتاحًا مؤقتًا وقصير الأمد للمعاملة من أجل التأكّد من أنّه وقّع الرمز المميّز. استخرِج هذا المفتاح من مطالبة cnf (التأكيد) في EVT، ثم استخدِمه للتحقّق من صحة رمز JWT المرتبط بالمفتاح.

بعد ذلك، احسب قيمة التجزئة المتوقّعة وقارِنها بالمطالبة sd_hash. يوضّح مثال Node.js التالي كيفية إجراء هذا الحساب:

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. التحقّق من صحة سجلّ نظام أسماء النطاقات

تأكَّد من سجلّ نظام أسماء النطاقات _email-verification لنطاق عنوان البريد الإلكتروني. على سبيل المثال، بالنسبة إلى demo@gmail.com، ابحث عن سجلّ _email-verification.gmail.com TXT. بالنسبة إلى موفّر الخدمة هذا، يعرض طلب البحث الموقع الجغرافي لموفّر الحساب، أي accounts.google.com.

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5- التعرّف على جهة الإصدار والتحقّق من توقيع EVT

تأكَّد من أنّ جهة الإصدار تعرض المورد /.well-known/email-verification الذي يوفّر نقاط النهاية لإصدار الرمز المميز ومفتاح الويب JSON (JWK) للموقع الإلكتروني وخوارزميات التوقيع المتوافقة.

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

استخدِم JWKs للتحقّق من صحة رمز EVT JWT الذي استخرجته من الرمز المميّز. توفّر معظم مكتبات JOSE وظائف للتعامل مع عملية التحقّق هذه.

في حال نجاح جميع الخطوات الخمس، تكون قد أثبتّ ملكية عنوان البريد الإلكتروني لدى مزوّد الخدمة. إذا لم يكن كذلك، عليك الرجوع إلى إرسال رسالة تأكيد إلكترونية إلى المستخدم وفقًا للمسار العادي.

تنفيذ خدمة مقدّم خدمة البريد الإلكتروني والجهة المصدرة

للحصول على تفاصيل إضافية، يمكنك الاطّلاع على الرمز التجريبي لموفّر البريد الإلكتروني الوهمي والرجوع إلى خطوات الجهة المصدرة في اقتراحي واجهة برمجة التطبيقات الخاصة بميزة "إثبات ملكية عنوان البريد الإلكتروني" وبروتوكول ميزة "إثبات ملكية عنوان البريد الإلكتروني".

بصفتك جهة إصدار، لست بحاجة إلى الاشتراك في مرحلة التجربة والتقييم أو تقديم رمز مميّز لأنّ سلوك المتصفّح يتم تنشيطه من خلال الموقع الإلكتروني الخاص بالجهة المعتمِدة. ما عليك سوى التأكّد من توفّر نقاط النهاية المتوقّعة للردّ على هذه الطلبات.

ضبط ميزة "اكتشاف جهة الإصدار"

للسماح للمتصفّحات باكتشاف نقاط نهاية التحقّق تلقائيًا عند اختيار عنوان بريد إلكتروني تابع لنطاقك، يجب عرض إعداداتك باستخدام نظام أسماء النطاقات ونقطة نهاية HTTP .well-known.

ضبط سجلّ تفويض نظام أسماء النطاقات

اضبط سجلّ TXT لنظام أسماء النطاقات على نطاق بريدك الإلكتروني يفوّض سلطة التحقّق إلى معرّف الجهة المصدرة. يمكن أن تستخدم هذه المعرّفات النطاق نفسه حسب البنية الأساسية.

تنسيق السجلّ: _email-verification.<email-domain>

مثال على ملف المنطقة:

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

استضافة نقطة نهاية `.well-known/email-verification`

استضافة ملف بيانات وصفية بتنسيق JSON على نطاق الجهة المصدرة ضمن المسار /.well-known/ يوضّح هذا الملف إمكانات الإصدار وخوارزميات التوقيع المشفر التي تتوافق مع بنيتك الأساسية.

نقطة النهاية: https://<issuer-domain>/.well-known/email-verification

مثال على الردّ:

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

استضافة نقطة نهاية `.well-known/web-identity`

أحد موارد JSON الإضافية .well-known التي ربما سبق لك تنفيذها كجزء من واجهة برمجة التطبيقات Federated Credentials (FedCM). يوفّر ذلك روابط إلى نقطة نهاية حساباتك وعنوان URL لتسجيل الدخول.

نقطة النهاية: https://<domain>/.well-known/web-identity

مثال على الردّ:

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

استخدام نقطة نهاية للحسابات

تقدّم نقطة نهاية الحسابات من واجهة برمجة التطبيقات FedCM قائمة بالحسابات التي تم تسجيل الدخول إليها في الوقت الحالي. يعرض المثال التالي ردًا بسيطًا. لمزيد من التفاصيل، يُرجى الرجوع إلى دليل تنفيذ موفِّر الهوية.

نقطة النهاية: كما هو محدّد في .well-known/web-identity

في ما يلي مثال على الرد:

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "demo@example.com",
      "given_name": "Demo"
    }
  ]
}

تحقيق التكامل مع Login Status API

يجب أن تكون لدى المستخدم جلسة نشطة مع مقدّم الخدمة، ويجب أن تشير إلى ذلك للمتصفّح باستخدام Login Status API.

عندما يسجّل المستخدم دخوله أو خروجه بنجاح، اعرض عنوان استجابة HTTP المطابق:

Set-Login: logged-in
Set-Login: logged-out

بدلاً من ذلك، يمكنك تعديل الحالة باستخدام JavaScript في سياق تطبيق الويب الخاص بك:

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

التعامل مع طلبات الإصدار

يتلقّى جهاز issuance_endpoint طلب application/x-www-form-urlencoded POST يتضمّن request_token.

توضّح الأقسام التالية العملية الكاملة للتعامل مع طلبات الإصدار.

1. التحقّق من صحة طلب الإصدار

تحليل حمولات المتصفّح الواردة والتحقّق من صحتها:

الطريقة: POST
التحقّق من الجلسة: تحقَّق من صحة ملفات تعريف الارتباط الخاصة بالطرف الأول للمستخدمsession/authentication التي يتم إرسالها مع الطلب للتأكّد من توفّر سياق هوية نشط ومفوَّض.
التحقّق من صحة المَعلمة: استخرِج المَعلمة request_token (وهي رمز JWT موقّع ينشئه المتصفّح). تأكَّد من أنّها تتضمّن المفتاح العام المؤقت المتوقّع والبريد الإلكتروني المستهدف والجمهور المناسب والطابع الزمني الصالح.

من المفترض أن يبدو الرمز المميّز الذي تم فك ترميزه على النحو التالي:

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "demo@example.com",
    "email": "demo@example.com",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. الردّ باستخدام رمز مميّز

بعد إكمال عملية التحقّق من صحة الرمز المميّز للجلسة ورمز الطلب بنجاح، أنشئ توقيعًا لرمز Selective Disclosure JWT (SD-JWT) باستخدام الحمولة:

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "demo@example.com",
  "email_verified": true
}

وقِّع الحمولة باستخدام مفتاحك الخاص والخوارزمية المتوافقة. على سبيل المثال، استخدام jose في Node.js:

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

مثال على استجابة ناجحة (HTTP 200):

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

اعتبارات مرحلة التجربة والتقييم

مراحل التجربة والتقييم هي تجارب تهدف إلى جمع الملاحظات، لذا فإنّ ملاحظاتك مهمة جدًا إذا شاركت فيها بصفتك طرفًا معتمدًا أو مقدّم خدمة هوية. للإبلاغ عن مشاكل، استخدِم مستودعات GitHub التالية:

واجهة برمجة التطبيقات للتحقّق من عنوان البريد الإلكتروني في المتصفّح: WICG/email-verification
بروتوكول تأكيد عنوان البريد الإلكتروني: dickhardt/email-verification

إذا واجهت أخطاء في تنفيذ Chrome، يُرجى الإبلاغ عن خطأ في المكوّن:

مشكلة جديدة: Chromium > Blink > Identity > EVP

يتم التحكّم في تفعيل وظائف مرحلة التجربة والتقييم على أساس كل ردّ على حدة من خلال تضمين رمز OT. وهذا يعني أنّه يمكنك التحكّم بدقة في هذه الميزة إذا كنت تفضّل حصرها على مجموعة من المستخدمين. على سبيل المثال، إذا كان لديك إطار عمل لاختبار A/B، يمكنك دمج مرحلة التجربة والتقييم فيه لتحديد مجموعة تجريبية خاضعة للرقابة. بدلاً من ذلك، إذا كان لديك مجموعة من المستخدمين المشاركين في اختبار تجريبي أو معاينة مبكرة، قد تحتاج إلى تفعيل الميزة لهم. في هذه الحالة، تحقَّق من عنوان البريد الإلكتروني المقدَّم قبل إصدار الرمز المميّز أو التحقّق من صحته.

تتضمّن مراحل التجربة والتقييم أيضًا حدودًا قصوى لعدد الزيارات بهدف تقليل عدد المواقع الإلكترونية التي تعتمد على الميزة قبل إطلاقها. لا تزال واجهة برمجة التطبيقات الخاصة بالجهة المصدرة قيد التطوير، لذا من المتوقّع حدوث تغييرات غير متوافقة مع الإصدارات السابقة بالإضافة إلى تحديثات لتجربة المستخدم في Chrome.

سننشر المزيد من الأخبار على المدوّنة هنا وعلى القائمة البريدية evp-announce@chromium.org مع تقدّم عملية التطوير.