الدليل الشامل لأخطاء WebAuthn في الإنتاج (2026)

تعد أخطاء WebAuthn في الإنتاج محيرة لأن المتصفحات تعرض مجموعة صغيرة من أسماء DOMException (مثل NotAllowedError) التي يمكن أن تمثل أسباباً أساسية متعددة. علاوة على ذلك، فإن الغالبية العظمى من "الأخطاء" - غالباً ما تتجاوز 95% في عمليات النشر واسعة النطاق المحسنة - هي في الواقع سلوك متوقع (قام المستخدم بإلغاء مطالبة مفتاح المرور لنظام التشغيل).

اختبر تدفقات passkey في Passkeys Debugger.

جرّب مجاناً

إذا كنت تريد التعريفات الأساسية لهذه الأسماء، فابدأ بـ MDN DOMException. بالنسبة لشروط WebAuthn المحددة التي تؤدي إلى هذه الاستثناءات (وما الذي يتطلب من المتصفحات فرضه)، راجع مواصفات مصادقة الويب من W3C.

إذا كنت تتعامل مع جميع الأخطاء على أنها "أخطاء برمجية"، فستفعل الأشياء الخاطئة:

• ستلوث مقاييس الأخطاء الخاصة بك بالإلغاءات العادية.
• ستفوتك التراجعات الحقيقية المخفية داخل كتلة NotAllowedError.
• ستنشر واجهة مستخدم تربك المستخدمين بدلاً من مساعدتهم على التعافي.

في هذا المقال نجيب على:

• ماذا تعني الأسماء الأكثر شيوعاً لأخطاء WebAuthn في حركة المرور الحقيقية؟
• كيف تميز NotAllowedError في مجموعات قابلة للتنفيذ (إلغاء مقابل مهلة مقابل التوفر)؟
• لماذا يعني نفس الخطأ أشياء مختلفة اعتماداً على العملية (تسجيل الدخول بواجهة مستخدم مشروطة مقابل تسجيل الدخول النمطي مقابل إنشاء مفتاح المرور مقابل الإنشاء المشروط)؟
• ما هو الحد الأدنى من السياق الذي يجب أن تلتقطه حتى يصبح "فشل" مشكلة قابلة للتحقيق؟

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

هناك شيء واحد يسهل تفويته: يمكن أن يعني نفس error.name أشياء مختلفة تماماً اعتماداً على نوع العملية. ضع في اعتبارك سياق العملية عند قراءة الأقسام أدناه. في الممارسة العملية، تتفوق أخطاء إنشاء مفتاح المرور (التسجيل) عادةً على أخطاء تسجيل الدخول بهامش كبير - ينطبق الجدول أعلاه على كليهما، لكن الإنشاء هو المكان الذي يعيش فيه معظم الحجم.

بعد ذلك، سنتعمق أكثر في NotAllowedError لأنها الأكثر ظهوراً والتي تسيء الفرق تفسيرها في أغلب الأحيان.

غالباً ما تبدو NotAllowedError كـ "فشل مفاتيح المرور"، ولكنها عادةً ما تكون النظام الأساسي الذي يخبرك بأن المستخدم لم يكمل واجهة مستخدم نظام التشغيل. المفتاح هو تقسيمها إلى مجموعات يمكنك التصرف بناءً عليها.

ما ستراه في وحدة تحكم المتصفح:

تظهر جميعها كـ error.name === "NotAllowedError". تختلف error.message باختلاف محرك المتصفح والسبب الأساسي، لكن النتيجة واحدة: لم يكتمل الحفل.

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

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

لست بحاجة إلى إشارة مثالية. تحتاج إلى سياق كافٍ لتجنب التعامل مع كل NotAllowedError بنفس الطريقة. يحصل iOS / Safari على اهتمام خاص أدناه لأن لديه قيوداً فريدة (متطلبات تنشيط المستخدم في الإصدارات السابقة)، ولكن في حجم الأخطاء الخام، غالباً ما تولد متصفحات Windows و Chromium NotAllowedError أكثر من أي نظام أساسي آخر. غالباً ما تصل بك هذه الإشارات إلى 80٪ من الطريق:

هذا هو السبب أيضاً في أنه نادراً ما يكون NotAllowedError مرئياً للمستخدم. إنها ليست رسالة يمكن للمستخدم التصرف بناءً عليها.

تصنيف السياق هو أيضاً المكان الذي تنقسم فيه معدلات النجاح بشكل حاد. يقيس تحليل معدل نجاح مصادقة مفتاح المرور لعام 2026 إكمال الربع الأول من عام 2026 بنسبة 55-95٪ للتدفقات التي تبدأ بمعرف الجهاز غير المعروف مقابل 95-99٪ لعوائد الجهاز المعروفة عبر عمليات النشر من الشركات إلى المستهلكين واسعة النطاق. يهبط المعرف الأول للويب على iOS بنسبة إكمال 85-95٪ (% CDA 0-5٪)، الويب على Android بنسبة 70-85٪ (% CDA 5-10٪) و macOS للويب بنسبة 70-85٪ (% CDA 10-15٪)، بينما يقع الويب على Windows بنسبة 45-60٪ من الإكمال الأول للمعرف مع % CDA بنسبة 55-65٪ على Windows 11 و 40-55٪ على Windows 10. إن قراءة حجم NotAllowedError دون فصل سياقات الجهاز المعروفة مقابل غير المعروفة يجمع بين نظامي نجاح مختلفين تماماً.

فارق بسيط واحد يهم في الإنتاج: قد تعرض بعض وكلاء المستخدمين المهلات كـ TimeoutError، لكن العديد من الفرق لا تزال ترى مهلة تنهار إلى NotAllowedError في لوحات المعلومات. في كلتا الحالتين، تعامل مع المهلات كـ "لم يكتمل الحفل" وقم بتجميعها باستخدام التوقيت بالإضافة إلى السياق.

عند رفض ورقة نظام التشغيل أو انتهاء مهلتها، يجب أن تتعافى واجهة المستخدم الخاصة بك فوراً وتتفاعل بكياسة. مجموعة عملية من القواعد:

• استعادة واجهة مستخدم تسجيل الدخول (لا توجد أداة دوارة تستمر في التشغيل)
• احتفظ بحالة المعرف (لا تفرض إعادة الإدخال)
• إظهار خطة احتياطية مرئية على نفس الشاشة
• تجنب اللافتات المخيفة للنتائج المتوقعة

ما وراء الأساسيات:

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

إذا كانت "إلغاءاتك" عالية حقاً، فإن الخطوة التالية هي إصلاح الأسباب الجذرية وراءها: توقيت المطالبة، ومفاجآت QR وانخفاض التوفر.

ابدأ بالتغييرات التي تحرك المقاييس بسرعة:

• إصلاح توقيت المطالبة وتنشيط المستخدم (خاصة على iOS/Safari): أحداث WebAuthn التي يتم تنشيطها بواسطة المستخدم في Safari.
• تقليل مفاجآت QR / الهجينة: لماذا تظهر تدفقات مفتاح المرور رموز QR ويتخلى المستخدمون.
• تقديم العروض البوابة بحيث يتم عرض مفاتيح المرور عندما يكون من المرجح أن تنجح: اعرض مفاتيح المرور فقط عندما يكون من المرجح أن تنجح.
• استخدم الأنماط التي تتجنب المطالبة في حالة عدم وجود بيانات اعتماد محلية: التوسط الفوري لـ WebAuthn.
• التعامل مع تقلبات الشبكة: غالباً ما تظهر أخطاء الشبكة أثناء التحقق كأخطاء عامة من جانب العميل. قم بتنفيذ قائمة انتظار غير متصلة بالإنترنت لسجلات القياس عن بُعد الخاصة بك حتى لا تفقد بيانات الخطأ عند انقطاع اتصال المستخدم أثناء الحفل.
• تأمين الاحتفالات مع واجهات برمجة تطبيقات الكشف بحيث لا تضخم حالات فشل البيئة مجموعة NotAllowedError الخاصة بك. ابدأ بـ isUVPAA() باعتبارها البوابة الأساسية، ثم استخدم getClientCapabilities() لإجراء عمليات فحص أدق (الإنشاء المشروط، والحصول المشروط، والنقل الهجين، والمصادق على النظام الأساسي). كن على علم بأن واجهات برمجة تطبيقات الكشف يمكن أن تتعطل مع تحديثات نظام التشغيل: شحنت iOS 26.2 خطأ WebKit حيث تعود isUVPAA() كـ false على جميع المتصفحات القائمة على WKWebView على الرغم من أن مفاتيح المرور تعمل بشكل جيد، مما تسبب في طفرات NotAllowedError مفاجئة لـ 10-25% من مستخدمي iOS (انظر إصلاح اكتشاف مفتاح المرور باستخدام getClientCapabilities()).

أسماء الأخطاء هدف متحرك. هناك مقترحات مستمرة لإضافة المزيد من أخطاء WebAuthn الدقيقة (على سبيل المثال، لفصل "لا توجد بيانات اعتماد متاحة" عن "ألغى المستخدم"). اعتباراً من فبراير 2026، لم يتم تنفيذ هذا في أي متصفحات، لذا لا يزال من الجدير بناء دلاء السبب الخاصة بك بناءً على السياق والتوقيت. إذا كنت ترغب في تتبع هذا العمل، فراجع مشكلة WebAuthn #2062 والموضح "رموز خطأ جديدة".

أسماء الأخطاء المتبقية أقل تواتراً ولكنها لا تزال تستحق الفهم عند ظهورها.

AbortError غير شائع في الحجم مقارنة بـ NotAllowedError، ولكن عندما يظهر يكون تشخيصياً للغاية: فهو يعني عادةً أن الحفل لم ينتهِ لأن تطبيقك أبطل الطلب - حدث التنقل، أو تغيرت الحالة، أو بدأ طلب ثانٍ.

ما ستراه في وحدة تحكم المتصفح:

تشمل أسباب الإنتاج الشائعة ما يلي:

• مكالمات WebAuthn متزامنة متعددة (مطالبتان تتسابقان)
• تغيير المسار / إعادة العرض أثناء حفل قيد التشغيل
• استدعاء AbortController.abort() أثناء إعادة المحاولة أو تنظيف الحالة

لإصلاح ذلك، ركز على جعل الحفل "قسماً حرجاً":

• السماح بطلب واحد قيد التشغيل في كل مرة
• منع التنقل أثناء الحفل (أو الإلغاء بشكل نظيف واستعادة واجهة المستخدم)
• التعامل مع الإجهاض كتدفق تحكم متوقع: إظهار زر إعادة المحاولة وطريقة احتياطية

إذا رأيت AbortError تتركز في الأسطح المضمنة أو تطبيقات متعددة المجالات، فإن المجموعة التالية التي يجب التحقق منها هي SecurityError.

يخبرك SecurityError المتصفح بأن: "هذا السياق لا يُسمح له بالقيام بما طلبته." في الممارسة العملية، يكون دائماً تكويناً تقريباً، وليس سلوك المستخدم. في عمليات النشر الإنتاجية الناضجة، نادرًا ما يكون SecurityError لأن هذه المشكلات عادةً ما يتم التقاطها أثناء اختبار التكامل. إذا ظهر في الإنتاج، فعادةً ما يعني ذلك أنه تم إضافة مجال جديد أو سياق تضمين أو هدف نشر بدون تكوين WebAuthn مناسب.

تشمل الأسباب الشائعة ما يلي:

• عدم تطابق معرف RP / الأصل (الإعدادات متعددة المجالات)
• قيود التضمين عبر الأصول (iframes)
• سياق غير آمن (ليس HTTPS) أو الأذونات / السياسات المحظورة
• .well-known/webauthn أو .well-known/assetlinks.json تم تكوينه بشكل غير صحيح أو مفقود أو غير متوفر مؤقتاً. ستتسبب مشكلات الشبكة خلال النافذة الحرجة عندما يجلب المتصفح هذه الملفات في حدوث أعطال. النقطة العمياء الشائعة: إذا كانت صفحتك الرئيسية معطلة للصيانة، فإن الملفات المعروفة تكون غير متصلة بالإنترنت، مما يكسر احتفالات مفتاح المرور عبر جميع الأطراف المعتمدة التي تعتمد عليها.

ما ستراه في وحدة تحكم المتصفح:

في الإنتاج، يعتبر SecurityError نادراً - يتم التقاط هذه الأشياء دائماً تقريباً أثناء اختبار التكامل. عند ظهورها، يكون خطأ شهادة TLS هو الناجي الأكثر شيوعاً.

حلقة التصحيح الأسرع هي:

• تسجيل مدخلات الأصل ومعرف RP التي استخدمتها
• إعادة الإنتاج في نفس السياق (المستوى الأعلى مقابل iframe، مجال الإنتاج مقابل التقسيم المرحلي)
• إذا قمت بتضمين تسجيل الدخول، فقم بتأكيد تكوين سياسة الأذونات (على سبيل المثال publickey-credentials-create / publickey-credentials-get): MDN Permissions-Policy
• التحقق من استراتيجية المجال الخاصة بك (راجع الأصول ذات الصلة)
• إذا كنت تستخدم iframes، فتحقق من صحة سياسات الميزات (راجع مفاتيح مرور iframe)

بمجرد التعامل مع SecurityError، فإن المجموعة التالية التي يجب التعامل معها بجدية هي مجموعة الأخطاء التي تشير غالباً إلى أخطاء في التنفيذ: InvalidStateError و ConstraintError و DataError.

ملخص Passkeys. إرشادات عملية وأنماط إطلاق ومؤشرات KPI لبرامج passkeys.

احصل على الملخص

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

ما ستراه في وحدة تحكم المتصفح:

المعاني النموذجية:

• التسجيل: حاولت إنشاء بيانات اعتماد موجودة بالفعل (نسخة مكررة)
• تسجيل الدخول: أقل شيوعاً؛ غالباً ما يعني أن التدفق / الحالة غير متسقة للمنصة

التعامل العملي:

• إذا حدث ذلك في التسجيل اليدوي، تعامل معه على أنه "تم التسجيل بالفعل" وقم بتوجيهه وفقاً لذلك
• تأكد من أن excludeCredentials يسرد جميع معرفات بيانات الاعتماد الموجودة للمستخدم حتى يتمكن المصادق من اكتشاف التكرارات (راجع excludeCredentials)
• أثناء الإنشاء المشروط، من المتوقع حدوث InvalidStateError ويجب تجاهله بصمت: هذا يعني أن مفتاح المرور موجود بالفعل في المزود. ينطبق الشيء نفسه على NotAllowedError و AbortError أثناء الإنشاء المشروط (راجع الإنشاء المشروط على Chrome)

المعنى النموذجي: لا يستطيع المصادق تلبية القيود المطلوبة.

المشغلات الشائعة:

• قفل شاشة الجهاز مفقود (خاصة على Android): يتطلب النظام الأساسي التحقق من المقاييس الحيوية أو رقم التعريف الشخصي ولكن الجهاز لا يحتوي على شاشة قفل تم تكوينها
• افتراضات authenticatorAttachment أو المفتاح المقيم صارمة جداً
• متطلبات userVerification الصارمة في القطاعات حيث لا تتوفر

الإصلاح: قم بتخفيف القيود (حيث يكون ذلك مقبولاً) أو توفير مسار بديل. بالنسبة لقفل الشاشة المفقود، فكر في اكتشاف هذا الشرط وتوجيه المستخدمين بدلاً من الفشل بصمت (Android).

المعنى النموذجي: المدخلات مشوهة أو غير متسقة.

المشغلات الشائعة:

• أخطاء التشفير (base64 مقابل base64url)
• تنسيق معرفات بيانات الاعتماد غير الصالحة / التحدي

الإصلاح: التحقق من صحة المدخلات وتطبيعها في الحدود التي تولد فيها خيارات WebAuthn. في الممارسة العملية، يكون DataError غائباً بشكل فعال في أنظمة الإنتاج الناضجة - إذا تم اختبار إنشاء الخيارات الخاص بك، فلن ترى هذا في لوحات المعلومات.

إذا كانت هذه الأخطاء تحت السيطرة، فإن السؤال التالي هو التغطية: هل يفشل المستخدمون لأن البيئة لا تستطيع القيام بـ WebAuthn بالطريقة التي تتوقعها؟

يُعد NotSupportedError إشارة تغطية، وليس إشارة موثوقية. ويعني هذا عادةً أن القطاع لا يستطيع القيام بما طلبته (نظام التشغيل / المتصفح قديم جداً، والقدرة مفقودة، والميزة غير ممكّنة).

ما ستراه في وحدة تحكم المتصفح:

الخطآن الأولان هما بالفعل DOMExceptions من نوع NotSupportedError. في حين أن إدخالات TypeError هي تقنياً نوع استثناء مختلف ولكنها تمثل نفس فئة المشكلة: المتصفح أو البيئة لا تدعم ما طلبته. تُعد عائلة تسلسل JSON TypeError أكثر شيوعاً في الممارسة العملية من DOMException الخاص بـ NotSupportedError (انظر أدناه).

تشمل الأسباب الشائعة ما يلي:

• المتصفحات / إصدارات نظام التشغيل القديمة التي لا تدعم WebAuthn الأساسي
• طلب ميزات WebAuthn غير متوفرة على هذا النظام الأساسي
• محاولة التدفقات الخاصة بالمنصة على الأجهزة غير المدعومة

عائلة تسلسل JSON هي أكبر مصدر لفشل فئة NotSupportedError في الإنتاج. من الناحية الفنية، تظهر هذه الأخطاء كـ TypeError (طريقة مفقودة)، وليس كـ DOMException، ولكن هذا هو المكان الذي ستواجهها فيه. هناك سببان جذريان متميزان:

1. لا يدعم المتصفح طرق تسلسل WebAuthn JSON. يحتوي المتصفح على navigator.credentials ولكن ليس PublicKeyCredential.parseCreationOptionsFromJSON / parseRequestOptionsFromJSON. يمثل هذا ما يقرب من 90٪ من عائلة الخطأ هذه، ويتركز في إصدارات Safari و Chrome الأقدم. إذا كانت مكتبة العميل الخاصة بك تعتمد على هذه الطرق بدون احتياطي، فإن ذلك يؤدي إلى حجم خطأ كبير.
2. ملحقات مدير كلمات المرور تعطل .toJSON(). يمكن للإضافات مثل Bitwarden أو LastPass أو 1Password اعتراض الحفل وإرجاع كائن يشبه بيانات الاعتماد ولكنه ليس نسخة فعلية من PublicKeyCredential. يؤدي استدعاء .toJSON() عليه إما إلى حدوث خطأ، أو إرجاع قيمة غير محددة، أو أن يكون الكائن فارغاً تماماً. هذا يمثل حوالي 10٪ من العائلة ولكنه محير بشكل خاص في تصحيح الأخطاء لأن رسائل الخطأ تختلف باختلاف المتصفح (Safari: "لا يمكن الاستدعاء إلا على مثيلات PublicKeyCredential"؛ Firefox: "لا ينفذ واجهة PublicKeyCredential").

يجب أن يكون التعامل صريحاً وسريعاً:

• التراجع فوراً إلى كلمة المرور الاحتياطية / كلمة المرور لمرة واحدة
• تسجيل المقطع حتى تتمكن من تحديد ثغرات التغطية كمياً
• تجنب إظهار عبارات الحث على اتخاذ إجراء بشأن مفتاح المرور على القطاعات التي ستفشل باستمرار

إذا كانت التغطية تبدو جيدة ولكن الفشل لا يزال يحدث في قطاعات معينة، فقد تكون تتعامل مع مشكلات طبقة النظام الأساسي التي تظهر على شكل UnknownError.

يُعد UnknownError خطأً جامعاً لفشل المصادق / نظام التشغيل الذي لا يتم تعيينه بشكل نظيف للفئات الأخرى. غالباً ما يكون عابراً، ولكن يمكن أن يرتفع أيضاً بعد تحديثات نظام التشغيل.

ما ستراه في وحدة تحكم المتصفح:

التعامل العملي:

• استخدم واجهة مستخدم صديقة لإعادة المحاولة (لا "تلوم المستخدم")
• التقاط أرقام نظام التشغيل / البناء وسياق مدير الاعتماد / المزود حيثما أمكن ذلك
• مراقبة الطفرات الخاصة بقطاع معين بعد تحديثات نظام التشغيل

مصدر خطأ متخصص واحد لا يتناسب بشكل أنيق مع أي فئة DOMException: يمكن لـ ملحقات متصفح مدير كلمات المرور (مثل Bitwarden، LastPass، 1Password، وغيرها) اعتراض مكالمات WebAuthn API وإرجاع استجابات غير قياسية. على الرغم من صغر حجمها مقارنة بإلغاءات المستخدم، فإن هذه الأمور تستحق التتبع لأنها تؤثر على شرائح محددة من المستخدمين بشكل مستمر وتكون الأعراض محيرة: طرق مفقودة في كائن بيانات الاعتماد التي تم إرجاعها، أو أنواع أخطاء غير متوقعة، أو استجابات مشوهة لا تتطابق مع أي خطأ WebAuthn موثق. غالباً ما تظهر هذه كـ UnknownError أو كاستثناءات غير مصنفة. إذا رأيت طفرات خطأ تتركز في متصفحات معينة مع عدم وجود تفسير على مستوى نظام التشغيل، فتحقق مما إذا كان امتداد مدير الاعتماد متورطاً.

لقد غطينا حتى الآن أسماء أخطاء متصفح الويب. ولكن إذا قمت أيضاً بشحن تطبيقات أصلية، فإن مشهد الأخطاء يكون مختلفاً - ومن نواحٍ عديدة، أفضل بكثير.

يغطي كل ما سبق متصفحات الويب. تشارك التطبيقات الأصلية - iOS مع إطار عمل ASAuthorization و Android مع واجهة برمجة تطبيقات Credential Manager - نفس الفئات الأساسية للأخطاء ولكنها تختلف بطرق مهمة:

1. "لا توجد بيانات اعتماد" هي إشارة مميزة. على الويب، تجمع المتصفحات "لا توجد بيانات اعتماد متوفرة" و "ألغى المستخدم" في نفس NotAllowedError للخصوصية. على المستوى الأصلي، يؤدي استخدام preferImmediatelyAvailableCredentials على نظام iOS (ASAuthorizationController) أو setPreferImmediatelyAvailableCredentials(true) على نظام Android (GetCredentialRequest) إلى إخبار نظام التشغيل بتقديم بيانات الاعتماد الموجودة بالفعل على الجهاز فقط والفشل فوراً في حالة عدم وجود أي منها. يمنحك هذا إرجاعاً نظيفاً لـ "عدم وجود بيانات اعتماد" لا يمكن أن يوفره الويب.

2. تظهر حالة مزود بيانات الاعتماد. يمكن للأنظمة الأساسية الأصلية في بعض الظروف أن تخبرك في حالة عدم تثبيت مزود بيانات اعتماد (مثل Google Password Manager، iCloud Keychain، 1Password، إلخ) أو تكوينه أو تعيينه كإعداد افتراضي والتفاعل مع ذلك. على الويب، يتم إخفاء هذه المعلومات خلف رسائل NotAllowedError غير الشفافة.

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

يعرض نظام iOS أخطاء مفتاح المرور من خلال إطار عمل ASAuthorization. تصل جميع الأخطاء في رد الاتصال المفوض authorizationController(controller:didCompleteWithError:) ككائنات NSError.

التصنيف حسب المجال + الرمز، وليس حسب سلسلة الرسائل. مجال الخطأ الأساسي هو com.apple.AuthenticationServices.AuthorizationError (ASAuthorizationError.errorDomain). قم بإلقاء الخطأ باستخدام let nsError = error as NSError وقم بمطابقته على .domain و .code. لا تتطابق أبداً على .localizedDescription في الإنتاج - يتم ترجمة رسائل Apple إلى أكثر من 30 لغة ويمكن أن تتغير عبر إصدارات نظام التشغيل. تُعد سلاسل الرسائل المدرجة أدناه مفيدة للتعرف على الأخطاء في السجلات، ولكنها ليست معايير تصنيف.

رموز ASAuthorizationError العامة:

التمييز الأكثر أهمية للإنتاج: منذ نظام التشغيل iOS 18، تعرض بيانات الاعتماد المكررة رمز الخطأ الخاص بها 1006 (MatchedExcludedCredential). على نظام التشغيل iOS 17 والإصدارات الأقدم، كانت بيانات الاعتماد المكررة مخفية داخل الرمز 1004 (Failed). في نظام التشغيل iOS 18 والإصدارات الأحدث، يكون التمييز هيكلياً (رمز خطأ مختلف)، وليس نصياً.

أخطاء وقت التشغيل الشائعة (مرجع على مستوى السجل):

تظهر هذه الرسائل في localizedDescription أو في userInfo لسيناريوهات فشل محددة. استخدمها لعمليات البحث عن السجلات وتصحيح الأخطاء، وليس للتصنيف البرمجي.

رسائل "لا توجد بيانات اعتماد" المترجمة (الرمز 1005):

عند تعيين preferImmediatelyAvailableCredentials ولم يكن هناك مفتاح مرور، يُرجع iOS الرمز 1005 (NotInteractive) مع رسالة مترجمة بلغة جهاز المستخدم. هذا فريد للتطبيقات الأصلية - لا تعرض متصفحات الويب هذه الإشارة أبداً. تبدأ الرسالة دائماً بـ The operation couldn't be completed. متبوعة بالنص المترجم:

عادةً ما تعمل أجهزة الإعدادات المحلية باللغة الإنجليزية على حل "عدم وجود بيانات اعتماد" على مستوى واجهة برمجة التطبيقات قبل أن يعرض إطار عمل ASAuthorization خطأ محلياً، ولهذا السبب لا يظهر أي متغير باللغة الإنجليزية أعلاه. برمجياً، قم دائماً بالمطابقة على الرمز 1005 بدلاً من تحليل هذه السلاسل.

يعرض Android أخطاء مفتاح المرور من خلال واجهة برمجة تطبيقات Credential Manager (androidx.credentials). تتضمن رسائل الخطأ رسالة أساسية وغالباً cause تحتوي على تفاصيل إضافية. بالمقارنة مع iOS، يوفر Android أنواع أخطاء أكثر تنظيماً وأسباباً أكثر وضوحاً لمشكلات التكوين.

إلغاء المستخدم واكتشاف بيانات الاعتماد:

أخطاء التكوين والأمان:

أخطاء المنصة والمصادق:

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

flowchart TD
    %% Global Styles
    classDef expected fill:#e3f2fd,stroke:#1565c0,stroke-width:2px;
    classDef unexpected fill:#ffebee,stroke:#c62828,stroke-width:2px;
    classDef network fill:#fff3e0,stroke:#ef6c00,stroke-dasharray: 5 5;
    classDef env fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1px;
    classDef action fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;

    %% --- LEFT SIDE: NETWORK & SERVER ---
    subgraph Infrastructure ["البنية التحتية (الخادم / الشبكة)"]
        direction TB
        ServerErr["خطأ في جانب الخادم<br/>500 / خطأ منطقي"]:::network
        NetErr["خطأ في الشبكة<br/>المهلة / 400 طلب غير صالح"]:::network

        ServerErr & NetErr -->|يظهر كـ| ClientManifest["خطأ عام من جانب العميل"]
    end

    %% --- CENTER: THE ENVIRONMENT STACK (From Sketch) ---
    subgraph Environment ["البيئة (جانب العميل)"]
        direction TB

        %% Layer 1: Platform Type
        subgraph Type ["الطبقة 1: المنصة"]
            Web["الويب / المتصفح"]
            Native["أصلي / تطبيق"]
        end

        %% Layer 2: OS Context
        subgraph OS_Layer ["الطبقة 2: نظام التشغيل والإصدار"]
            OS_Web["نظام التشغيل: Windows, macOS, Linux"]
            OS_Nat["نظام التشغيل: iOS, Android"]
            OS_Ver["إصدار نظام التشغيل / الإعدادات<br/>(قفل الشاشة، المقاييس الحيوية)"]

            Web --> OS_Web
            Native --> OS_Nat
            OS_Web & OS_Nat --> OS_Ver
        end

        %% Layer 3: Client Software
        subgraph Client_Layer ["الطبقة 3: برنامج العميل"]
            Browser["المتصفح: Chrome, Safari, Edge<br/>+ الإصدار"]
            App["التطبيق الأصلي / WebView<br/>+ إصدار التطبيق"]

            OS_Ver --> Browser
            OS_Ver --> App
        end

        %% Layer 4: WebAuthn Operation
        subgraph Op_Layer ["الطبقة 4: عملية WebAuthn"]
            OpType{"نوع العملية"}

            Login["تسجيل الدخول<br/>(navigator.credentials.get)"]
            Reg["التسجيل<br/>(navigator.credentials.create)"]

            Browser & App --> OpType
            OpType --> Login
            OpType --> Reg
        end

        %% Layer 5: Sub-types & Complexity
        subgraph Modality ["الطبقة 5: الطريقة والتعقيد"]
            Sub_CUI["CUI / واجهة مستخدم مشروطة"]
            Sub_Auto["عملية تلقائية"]
            Sub_CDA["CDA / المصادقة عبر الأجهزة"]

            Login & Reg --> Sub_CUI
            Login & Reg --> Sub_Auto
            Login & Reg --> Sub_CDA
        end
    end

    %% --- BOTTOM: CLASSIFICATION & ACTION (The "What here?" section) ---
    subgraph Analysis ["تحليل الأخطاء ووقت التشغيل"]
        direction TB

        %% Classification
        Classification{"التصنيف"}

        Exp["خطأ متوقع<br/>(ألغى المستخدم الحفل)"]:::expected
        Unexp["خطأ غير متوقع<br/>(نظام / تعطل / غير معروف)"]:::unexpected

        ClientManifest --> Classification
        Sub_CUI & Sub_Auto & Sub_CDA --> Classification

        Classification --> Exp
        Classification --> Unexp

        %% Detection Logic
        subgraph Detection ["أهداف الكشف"]
            P1["P1: مشاكل تسجيل الدخول"]
            P2["P2: مشاكل الإنشاء"]
            Baseline["كشف انجراف خط الأساس<br/>(زيادة المتوقع)"]
            NewErr["كشف الانحرافات الجديدة<br/>(زيادة غير المتوقع)"]
        end

        Exp --> Baseline
        Unexp --> NewErr
        Exp & Unexp --> P1 & P2

        %% Actionable Outcomes
        subgraph Action ["إجراءات التخفيف"]
            Fix["نشر إصلاح عاجل / إصدار جديد"]:::action
            Fallback["تنشيط الخطة الاحتياطية التلقائية<br/>(تعطيل مفتاح المرور)"]:::action
        end

        P1 & P2 & NewErr --> Fix
        P1 & P2 & NewErr --> Fallback
    end

    %% Connectors
    Infrastructure -.-> Environment

الفكرة الأساسية: لا يكون error.name الخام منطقياً إلا بمجرد معرفة أي طبقة من البيئة أنتجته، والعملية التي كانت قيد التشغيل، وما إذا كان الخطأ متوقعاً أو غير متوقع. تغطي الأقسام أدناه ما يجب تسجيله وكيفية التصرف بناءً عليه.

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

الشرط الأساسي: يجب أن تكون كل محاولة قابلة للدمج من البداية إلى النهاية. يربط معرف الارتباط المشترك (مثل auth_flow_id) السياق من جانب العميل بنتيجة تحقق الخادم.

تحدث حالات فشل التحقق من الخادم بعد أن يعرض المتصفح بيانات الاعتماد وتحدياً موقعاً. يجب أن تكون هذه الأخطاء أخطاء منظمة برموز صريحة، وليست مختلطة في نفس دلو أسماء DOMException الخاصة بجانب العميل. انظر: تنفيذ خادم WebAuthn.

إذا كنت تريد نموذج قمع كامل (الانقطاعات حسب الخطوة والتحويل بين الخطوات)، راجع: بيانات القياس عن بُعد لمفتاح المرور لفهم الانقطاعات.

اشترك في Passkeys Substack للحصول على آخر الأخبار.

اشترك

ومع وجود هذه البيانات في مكانها الصحيح، يصبح الاستنتاج بسيطاً: تصبح معظم "الأخطاء" إما إصلاحات لتجربة المستخدم، أو إصلاحات للتغطية، أو إصلاحات للتكوين. ولكن بناء هذا التصنيف والحفاظ عليه بنفسك هو عمل مستمر كبير.

تسجل قائمة التحقق من التسجيل أعلاه الإشارات الخام. في الإنتاج على نطاق واسع، لا يكفي error.name وحده. يعد بناء هذا التصنيف بنفسك عملاً مستمراً كبيراً: تتغير رسائل الأخطاء مع كل متصفح وإصدار نظام تشغيل، ويقدم مزودو مدير كلمات المرور تحديثات تغير سلوك الحفل، وتظهر توقيعات أخطاء جديدة مع كل ميزة يتم إطلاقها.

يمكن أن يعني NotAllowedError نفسه ستة أشياء مختلفة اعتماداً على ثلاثة أبعاد لا تفصلها المتصفحات لك:

هذه هي المشكلة التي تم تصميم حزمة أدوات المراقبة من Corbado لحلها. إنها تكامل واجهة أمامية خفيف الوزن يجلس أعلى تطبيق مفتاح المرور الحالي الخاص بك، ويعمل مع أي خادم WebAuthn وأي موفر هوية (IDP)، ويصنف كل خطأ WebAuthn عبر الأبعاد الثلاثة تلقائياً:

هذه هي طبقة المراقبة (Observe): الرؤية لما يحدث، دون تغيير تنفيذك.

تدعم وحدة تحكم الإدارة في Corbado مسارين للتحقيق:

من أعلى إلى أسفل (لوحة القيادة إلى السبب الجذري):

1. مراقبة نوعين متميزين من الشذوذ:
   • زيادة الأخطاء المتوقعة (انحراف الخط الأساسي): هل شهدت بيئة معينة (مثل نظام التشغيل iOS 18.2 على جهاز iPhone 15) زيادة تدريجية في "إلغاءات المستخدم"؟ يشير هذا غالباً إلى احتكاك في تجربة المستخدم ناتج عن تحديث لنظام التشغيل.
   • زيادة الأخطاء غير المتوقعة (طفرات): خطأ جديد تماماً أو قفزة مفاجئة في الإخفاقات. يشير هذا عادةً إلى تغيير جذري (تحديث مكدس IDP داخلي) أو تراجع في إصدار متصفح جديد.
2. تحديد الأولويات حسب التأثير:
   • P1: مشاكل تسجيل الدخول. إذا انخفضت معدلات نجاح تسجيل الدخول، فقم بالتنبيه على الفور.
   • P2: مشاكل الإنشاء. راقب الاتجاهات، ولكن تجنب إيقاظ المهندسين بسبب ارتفاع "إلغاء المستخدم" في تدفقات الإنشاء.
3. التنقل داخل البيئة: استخدم الأبعاد الحبيبية (الأجهزة، وإعدادات المصادقة) لعزل ما إذا كانت المشكلة عالمية أم خاصة بـ "أجهزة Samsung التي تعمل بنظام Android 14".
4. التخفيف من الآثار: في حالة اكتشاف ارتفاع حرج، اجعل مفتاح الإيقاف (Kill Switch) جاهزاً. قم بتعطيل مفاتيح المرور تلقائياً أو يدوياً لتلك البيئة المحددة واستخدم كلمات المرور لمرة واحدة / كلمات المرور كاحتياطي للحفاظ على معدلات تسجيل الدخول أثناء التحقيق.

من أسفل إلى أعلى (أنماط الأخطاء إلى التأثير):

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

كلا المسارين يتقاربان: من أعلى إلى أسفل يخبرك بأن هناك خطأ ما، ومن أسفل إلى أعلى يخبرك بالسبب. يربط مساعد تحليلات الذكاء الاصطناعي (AI Analytics Assistant) بين الاثنين من خلال السماح لك بطرح أسئلة باللغة الطبيعية عبر كل من بيانات الخطأ ومقاييس التبني.

بالنسبة للفرق التي ترغب في التصرف بناءً على هذه الإشارات، يمكنها الانتقال إلى التبني (Adopt)، الذي يضيف ذكاء مفتاح المرور إلى الاحتفالات التلقائية، وتحسين مطالبات التسجيل، ومعالجة حالات مفتاح المرور المعطلة. بالنسبة للبيئات المنظمة أو عمليات النشر على نطاق واسع، يضيف المؤسسات (Enterprise) استضافة المستأجر الفردي، وتكامل SIEM، والتكوين المتوافق مع PSD2.

احصل على ورقة بيضاء مجانية حول passkeys للمؤسسات.

احصل عليه مجاناً

أسماء أخطاء WebAuthn ليست حكماً. إنها تلميحات - وتصبح قابلة للتنفيذ فقط عند ربطها بنوع العملية والتوقيت وسياق النظام الأساسي.

• ماذا تعني أسماء أخطاء WebAuthn الأكثر شيوعاً في الإنتاج؟ معظمها يتوافق مع مجموعة صغيرة من الطبقات: التحكم في تدفق المستخدم (NotAllowedError)، ودورة حياة التطبيق / التزامن (AbortError)، وسياق الأمان / التكوين (SecurityError)، أو أخطاء الخيار / الحالة (InvalidStateError, ConstraintError, DataError). الغالبية العظمى من الحجم هو NotAllowedError، ومعظم هذا السلوك متوقع (رفض المستخدم للمطالبة).
• كيف تميز NotAllowedError؟ استخدم التوقيت (الرفض الفوري مقابل إلغاء المستخدم مقابل المهلة)، ومؤشر الاستجابة السريعة / الهجين (عدم تطابق التوفر)، وسياق تنشيط المستخدم (خاصة على iOS/Safari)، ونوع العملية (واجهة مستخدم مشروطة مقابل تسجيل الدخول النمطي مقابل إنشاء مفتاح مرور مقابل إنشاء مشروط). لا تعامل جميع NotAllowedError كوضع فشل واحد.
• لماذا يهم نوع العملية؟ يمثل error.name نفسه أثناء تسجيل الدخول بواجهة مستخدم مشروطة إشارة مختلفة تماماً عما هو عليه أثناء الإنشاء المشروط أو الإنشاء اليدوي لمفتاح المرور (رفض المستخدم لمربع الحوار). تسجيل نوع العملية بجانب الخطأ هو ما يحول NotAllowedError العام إلى دلو قابل للتنفيذ.
• ما هو الحد الأدنى من السياق الذي يجعل الأخطاء قابلة للتصحيح؟ التقاط error.name، ونوع العملية، ووقت الخطأ من بداية العملية، ونوع التدفق، وما إذا تم عرض واجهة مستخدم الاستجابة السريعة / الهجينة، ونظام التشغيل/المتصفح/الجهاز (بما في ذلك الإصدارات)، ومعرف الارتباط (auth_flow_id) ورفض تحقق الخادم كرموز صريحة.

هناك قاعدتان عامتان تتقاطعان مع جميع أنواع الأخطاء: لا تعرض أبداً أخطاء المتصفح الخام للمستخدمين - قم دائماً بتوفير مسار احتياطي واضح - وافصل المحاولات المحلية عن المحاولات الهجينة/الاستجابة السريعة (QR) عبر الأجهزة، لأنها تفشل لأسباب مختلفة وتحتاج إلى إصلاحات مختلفة. على نطاق واسع، يعد الحفاظ على تصنيف الأخطاء عبر المتصفحات وإصدارات نظام التشغيل ومديري كلمات المرور عملاً مستمراً. فكر في استخدام حزمة أدوات تطوير للمراقبة (SDK) مع مكتبة أنماط مُدارة بدلاً من بناء ذلك من الصفر.

حول Corbado

Corbado هي Authentication Intelligence Platform لفِرَق CIAM التي تُدير المصادقة الاستهلاكية على نطاق واسع. نُمكّنك من رؤية ما لا تستطيع سجلات IDP وأدوات التحليل العامة إظهاره: أي الأجهزة وإصدارات أنظمة التشغيل والمتصفحات ومديري بيانات الاعتماد تدعم passkeys، ولماذا لا تتحوّل عمليات التسجيل إلى عمليات دخول، وأين يفشل تدفق WebAuthn، ومتى يُعطّل تحديث نظام التشغيل أو المتصفح تسجيل الدخول بصمت — كل ذلك دون استبدال Okta أو Auth0 أو Ping أو Cognito أو IDP الداخلي لديك. منتجان: Corbado Observe يُضيف observability للـ passkeys وأي طريقة دخول أخرى. Corbado Connect يُقدّم managed passkeys مع تحليلات مدمجة (إلى جانب IDP الخاص بك). تُشغّل VicRoads passkeys لأكثر من 5 ملايين مستخدم مع Corbado (تفعيل passkey بنسبة +80%). تحدث مع خبير Passkey →

على الويب، تدمج المتصفحات كلتا الحالتين في NotAllowedError لأسباب تتعلق بالخصوصية، لذا لا يمكنك التمييز بينهما مباشرة. استخدم التوقيت كبديل: الخطأ تحت ثانية واحدة يعني عادةً رفض البيئة أو عدم توفر الإمكانية، بينما 1-15 ثانية تشير إلى أن المستخدم رأى مربع الحوار وتجاهله. في تطبيقات iOS و Android الأصلية، يوفر تعيين preferImmediatelyAvailableCredentials قبل الطلب إشارة "لا توجد بيانات اعتماد" واضحة (رمز iOS 1005، و GetCredentialRequest في Android) قبل عرض أي واجهة مستخدم.

في عمليات نشر مفتاح المرور المحسّنة واسعة النطاق، أكثر من 95٪ من أخطاء WebAuthn المسجلة هي إحباطات متوقعة من قبل المستخدم، وليست إخفاقات في النظام. إن تتبع أعداد error.name الأولية دون فصل "مربع حوار رفضه المستخدم" عن الإخفاقات الحقيقية يؤدي إلى تضخيم مقاييس الخطأ ويخفي التراجعات الحقيقية المخفية داخل حجم NotAllowedError. قسّم أعدادك حسب نوع العملية وتعامل مع دلاء إلغاء المستخدم بشكل منفصل عن الأخطاء غير المتوقعة مثل SecurityError و ConstraintError و DataError.

يعني رمز iOS 1005 (NotInteractive) أنه لا يوجد مفتاح مرور متاح على الجهاز عند تعيين preferImmediatelyAvailableCredentials على ASAuthorizationController، ولم يتم عرض واجهة مستخدم للمستخدم. هذه هي إشارة "لا يوجد مفتاح مرور على هذا الجهاز" النظيفة التي لا تستطيع متصفحات الويب توفيرها بسبب قيود الخصوصية. صنف دائماً بناءً على الرمز الرقمي، وليس على localizedDescription، لأن رسائل Apple مترجمة إلى أكثر من 30 لغة ويمكن أن تتغير عبر إصدارات نظام التشغيل.

أثناء الإنشاء المشروط، تُعد الأخطاء NotAllowedError و AbortError و InvalidStateError نتائج متوقعة ويجب تجاهلها بصمت بدلاً من ظهورها كأخطاء. يشير NotAllowedError إلى أن الملء التلقائي غير متاح أو أن الصفحة فقدت التركيز، بينما يعني InvalidStateError أن مفتاح المرور موجود بالفعل في المزود. قبل محاولة الاتصال، استخدم getClientCapabilities() للتحقق من دعم conditionalCreate والتحقق من حالة رؤية المستند لتجنب تضخيم عدد الأخطاء.

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