مشکلات رایج و گزارش اشکالات

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

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

هنگام توسعه و آزمایش فشار وب، دو مرحله متمایز وجود دارد که هر کدام مجموعه ای از مسائل/مشکلات مشترک خاص خود را دارند:

  • ارسال پیام: مطمئن شوید که ارسال پیام با موفقیت انجام شده است. شما باید یک کد HTTP 201 دریافت کنید. اگر نیستید:
    • خطاهای مجوز را بررسی کنید: اگر یک پیام خطای مجوز دریافت کردید به بخش مسائل مجوز مراجعه کنید.
    • سایر خطاهای API: اگر پاسخ کد وضعیت غیر 201 را دریافت کردید، برای راهنمایی در مورد علت مشکل به بخش کدهای وضعیت HTTP مراجعه کنید.
  • دریافت پیام : اگر می‌توانید پیامی را با موفقیت ارسال کنید، اما پیام در مرورگر دریافت نشد:

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

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

مسائل مربوط به مجوز

مسائل مربوط به مجوز یکی از رایج ترین مشکلاتی است که توسعه دهندگان هنگام شروع کار با فشار وب با آن مواجه می شوند. این معمولاً یک مشکل در پیکربندی کلیدهای سرور کاربردی سایت (با نام مستعار کلیدهای VAPID) است.

ساده ترین راه برای پشتیبانی از push در فایرفاکس و کروم، ارائه یک applicationServerKey در فراخوانی subscribe() است. نکته منفی این است که هر گونه اختلاف بین کلیدهای جلویی شما و سرور منجر به خطای مجوز می شود.

در کروم و FCM

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

در هر یک از شرایط زیر یک خطای UnauthorizedRegistration دریافت خواهید کرد:

  • اگر نتوانستید یک عنوان Authorization را در درخواست به FCM تعریف کنید.
  • کلید برنامه مورد استفاده شما برای اشتراک کاربر با کلید مورد استفاده برای امضای سرصفحه مجوز مطابقت ندارد.
  • انقضا در JWT شما نامعتبر است، یعنی انقضا بیش از 24 ساعت است یا JWT منقضی شده است.
  • JWT نادرست است یا مقادیر نامعتبری دارد.

پاسخ کامل خطا به این صورت است:

<html>
  <head>
    <title>UnauthorizedRegistration</title>
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <h1>UnauthorizedRegistration</h1>

    <h2>Error 400</h2>
  </body>
</html>

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

Firefox و Mozilla AutoPush

فایرفاکس و Mozilla AutoPush مجموعه ای دوستانه از پیام های خطا را برای مسائل Authorization ارائه می کنند.

همچنین اگر سرصفحه Authorization در درخواست فشار شما گنجانده نشده باشد، یک پاسخ خطای Unauthorized از Mozilla AutoPush دریافت خواهید کرد.

{
  "errno": 109,
  "message": "Request did not validate missing authorization header",
  "code": 401,
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "error": "Unauthorized"
}

اگر انقضا در JWT شما منقضی شده باشد، همچنین یک خطای Unauthorized با پیامی دریافت خواهید کرد که توضیح می دهد که توکن منقضی شده است.

{
  "code": 401,
  "errno": 109,
  "error": "Unauthorized",
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "message": "Request did not validate Invalid bearer token: Auth expired"
}

اگر کلیدهای سرور برنامه بین زمانی که کاربر مشترک شده است و زمانی که سربرگ مجوز امضا شده است متفاوت باشد، یک خطای Not Found برگردانده می شود:

{
  "errno": 102,
  "message": "Request did not validate invalid token",
  "code": 404,
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "error": "Not Found"
}

در نهایت، اگر مقدار نامعتبری در JWT خود داشته باشید (به عنوان مثال اگر مقدار "alg" یک مقدار غیرمنتظره باشد)، خطای زیر را از Mozilla AutoPush دریافت خواهید کرد:

{
  "code": 401,
  "errno": 109,
  "error": "Unauthorized",
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "message": "Request did not validate Invalid Authorization Header"
}

کدهای وضعیت HTTP

طیف وسیعی از مسائل وجود دارد که می تواند منجر به کد پاسخ غیر 201 از یک سرویس فشار شود. در زیر لیستی از کدهای وضعیت HTTP و معنای آنها در رابطه با فشار وب آمده است.

کد وضعیت شرح
429 درخواست های خیلی زیاد سرور برنامه شما با یک سرویس فشار به حداکثر نرخ رسیده است. پاسخ سرویس باید شامل سرصفحه «تعداد مجدد-پس از» باشد تا نشان دهد چه مدت قبل از درخواست دیگری می‌توان انجام داد.
400 درخواست نامعتبر یکی از هدرهای شما نامعتبر است یا قالب بندی ضعیفی دارد.
404 پیدا نشد. در این صورت باید PushSubscription را از قسمت پشتی خود حذف کنید و منتظر فرصتی برای اشتراک مجدد کاربر باشید.
410 رفته. اشتراک دیگر معتبر نیست و باید از قسمت پشتی شما حذف شود. این را می توان با فراخوانی 'unsubscribe()' در 'PushSubscription' بازتولید کرد.
413 اندازه بار بسیار بزرگ است. حداقل اندازه باری که یک سرویس فشار باید پشتیبانی کند 4096 بایت (یا 4 کیلوبایت) است. هر چیزی بزرگتر می تواند منجر به این خطا شود.

اگر کد وضعیت HTTP در این لیست نیست و پیام خطا مفید نیست، مشخصات پروتکل Web Push را بررسی کنید تا ببینید آیا کد وضعیت به همراه سناریویی از زمان استفاده از آن کد وضعیت ارجاع داده شده است یا خیر.

مشکل رمزگذاری بار

اگر بتوانید یک پیام فشار را با موفقیت راه اندازی کنید (یعنی پیامی را به یک سرویس فشار وب ارسال کنید و کد پاسخ 201 را دریافت کنید) اما رویداد فشار هرگز در سرویس کار شما فعال نمی شود، این معمولاً نشان می دهد که مرورگر در رمزگشایی پیامی که دریافت کرده است شکست خورده است.

اگر چنین است، باید یک پیام خطا در کنسول DevTools فایرفاکس مشاهده کنید:

فایرفاکس DevTools با پیام رمزگشایی.

برای بررسی اینکه آیا این مشکل در کروم است، موارد زیر را انجام دهید:

  1. به about://gcm-internals بروید و روی دکمه «شروع ضبط» کلیک کنید.

رکورد داخلی کروم GCM.

  1. یک پیام فشار را راه اندازی کنید و به زیر "گزارش شکست رمزگشایی پیام" نگاه کنید.

گزارش رمزگشایی داخلی GCM.

اگر مشکلی در رمزگشایی محموله وجود داشته باشد، خطای مشابهی را مشاهده خواهید کرد که در بالا نشان داده شده است. (به پیام AES-GCM decryption failed در ستون جزئیات توجه کنید.)

در صورت بروز مشکل، چند ابزار وجود دارد که ممکن است به رفع اشکال رمزگذاری کمک کند:

مشکل اتصال

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

در Chrome، می‌توانید با بررسی «گزارش دریافت پیام» (sic) در about://gcm-internals بررسی کنید که آیا مرورگر پیام‌ها را دریافت می‌کند یا خیر.

GCM داخلی گزارش پیام را دریافت می کند.

اگر پیام را به موقع نمی بینید، مطمئن شوید که وضعیت اتصال مرورگر شما CONNECTED است:

وضعیت اتصال داخلی GCM.

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

افزایش گزارش اشکال

اگر هیچ یک از موارد بالا به مشکل شما کمک نمی کند و هیچ نشانه ای از مشکل وجود ندارد، لطفاً مشکلی را در مورد مرورگری که با آن مشکل دارید مطرح کنید:

برای کروم، باید این مشکل را در اینجا مطرح کنید: https://bugs.chromium.org/p/chromium/issues/list برای فایرفاکس، باید این مشکل را در این آدرس مطرح کنید: https://bugzilla.mozilla.org/

برای ارائه یک گزارش اشکال خوب، باید جزئیات زیر را ارائه دهید:

  • مرورگرهایی که در آنها آزمایش کرده اید (به عنوان مثال کروم نسخه 50، کروم نسخه 51، فایرفاکس نسخه 50، فایرفاکس نسخه 51).
  • نمونه ای PushSubscription که مشکل را نشان می دهد.
  • هر گونه درخواست نمونه (به عنوان مثال محتوای درخواست های شبکه به یک سرویس فشار، از جمله هدر) را درج کنید.
  • هر گونه پاسخ نمونه از درخواست های شبکه را نیز درج کنید.

اگر بتوانید یک مثال قابل تکرار، چه کد منبع یا یک وب سایت میزبانی شده ارائه دهید، اغلب تشخیص و حل مشکل را سرعت می بخشد.

بعد کجا بریم

آزمایشگاه های کد