خطاها و حالت‌های شکست

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

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

کاربر پنجرهٔ مجوزدهی متا را باز کرده و تصمیم گرفته ادامه ندهد. متا کاربر را با خطایی که نشان‌دهندهٔ رد درخواست است به نشانی بازگشت برمی‌گرداند، نه با کد مجوزدهی.

• این یک نتیجهٔ طبیعی است، نه نقص. هیچ توکنی صادر و هیچ داده‌ای ذخیره نمی‌شود.
• هما کاربر را به صفحهٔ خطای مجوزدهی با امکان تلاش مجدد هدایت می‌کند.
• کوکی یک‌بارمصرف state پاک می‌شود تا تلاش بعدی از ابتدا و پاک آغاز شود.

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

• علت بی‌خطر: کاربر به‌قدری صبر کرده که کوکی کوتاه‌عمر منقضی شده، یا جریان را در مرورگر یا پنجرهٔ ناشناس دیگری تکمیل کرده است.
• علت بی‌خطر: کوکی‌ها مسدود هستند، بنابراین state هرگز ذخیره نشده است.
• علت خرابکارانه: تلاش برای جعل درخواست بین‌سایتی، که در آن مهاجم کد مجوزدهی خود را تحمیل می‌کند.

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

• این خطا پیش از آنکه از کاربر چیزی خواسته شود بروز می‌کند، معمولاً روی خود پنجرهٔ متا.
• خطای پیکربندی است نه خطای کاربر، بنابراین تلاش مجدد بدون اصلاح کمکی نمی‌کند.
• علت‌های رایج: یک اسلش اضافه در انتها، http به‌جای https، محیطی که به میزبان نادرست اشاره می‌کند، یا نشانی بازگشتی که روی اپلیکیشن متای دیگری ثبت شده است.

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

• توکن معتبر است و سایر قابلیت‌ها به کار خود ادامه می‌دهند.
• قابلیت وابسته به‌عنوان «در دسترس نیست» نشان داده می‌شود و توضیح داده می‌شود کدام توانایی غایب است.
• بازیابی یعنی مجوزدهی تازه‌ای که در آن کاربر مجوز باقی‌مانده را اعطا کند.

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

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

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

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

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

• درخواست‌ها با عقب‌نشینی نمایی و پراکندگی تصادفی بازآزمایی می‌شوند، نه در حلقهٔ تلاش فوری.
• تلاش مجدد پرفشار پنجرهٔ محدودسازی را طولانی‌تر و بازیابی را کندتر می‌کند.
• پردازش وب‌هوک صف‌محور است، بنابراین انبوهی از رویدادها جذب می‌شود و به انبوهی از فراخوانی API تبدیل نمی‌شود.
• محدودسازی پایدار به‌عنوان پردازش کاهش‌یافته نمایش داده می‌شود، نه خطای قطعی.

یک درخواست ورودی وب‌هوک امضای غایب یا نادرست داشته است. محتوا بدون آنکه به‌عنوان رویداد دامنه تفسیر شود دور انداخته می‌شود.

• نقطهٔ پایانی پاسخ می‌دهد بدون آنکه فاش کند امضا، مهر زمانی یا بدنه مقصر بوده است.
• هر تحویل ردشده به‌عنوان رویداد امنیتی ثبت می‌شود، زیرا افزایش نرخ آن نشانهٔ کاوش است.
• خوشه‌ای ناگهانی از شکست‌ها روی ترافیکی که پیش‌تر کار می‌کرد، معمولاً یعنی راز اپلیکیشن در یک سو چرخانده شده و در سوی دیگر نه.

APIهای متا در دسترس نیستند یا کارایی کاهش‌یافته دارند. هما نمی‌تواند این را رفع کند و آن را به‌عنوان نقص هما نمایش نمی‌دهد.

• کارهای صف‌شده حفظ و بازآزمایی می‌شوند، نه دور انداخته.
• کانال متأثر به‌عنوان دارای کارایی کاهش‌یافته گزارش می‌شود، در حالی که بخش‌های متأثرنشدهٔ محصول به کار خود ادامه می‌دهند.
• در دسترس بودن APIهای شخص ثالث خارج از کنترل هما است، همان‌گونه که در شرایط استفاده از خدمات آمده است.

یک مقدار لازم در سمت سرور غایب یا نامعتبر است. نمایان‌ترین نمونه، نبود نشانی مجوزدهی است که کنش اتصال را از کار می‌اندازد.

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

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