
گاهی مشتری محصولی را به سبد خرید ووکامرس اضافه میکند، اما هنگام تغییر تعداد کالا، اعمال کد تخفیف یا تکمیل پرداخت با خطا روبهرو میشود. ممکن است بخش تسویهحساب مدام در حال بارگذاری باشد یا پس از ثبت سفارش پیام نامشخصی نمایش داده شود. یکی از مسیرهای مهم برای پیدا کردن علت، بررسی درخواستهای Store API ووکامرس است.
برطرف کردن این خطاها به معنای خاموش کردن فایروال، غیرفعال کردن افزونه امنیتی یا حذف بررسی توکنها نیست. با مشاهده پاسخ درخواست و گزارش رویدادهای امنیتی میتوان علت را شناسایی و تنها بخش مشکلدار را اصلاح کرد. این آموزش را ابتدا در محیط آزمایشی انجام دهید.
Store API ووکامرس چیست و چگونه با سبد و پرداخت ارتباط دارد؟
Store API بخشی از زیرساخت ووکامرس برای قابلیتهای سمت خریدار است. بلوکهای سبد خرید و تسویهحساب برای دریافت اطلاعات سبد، بروزرسانی کالاها و اجرای فرایندهای خرید از آن استفاده میکنند. این رابط برای استفاده مشتریان طراحی شده است، اما عملیات تغییر سبد و پرداخت به سازوکار اعتبارسنجی مانند Nonce یا Cart Token وابستهاند.
چند نمونه از مسیرهای مرتبط عبارتاند از:
/wp-json/wc/store/v1/cart
/wp-json/wc/store/v1/cart/add-item
/wp-json/wc/store/v1/cart/update-item
/wp-json/wc/store/v1/checkout
نباید همه مشکلات پرداخت را به Store API نسبت داد. اگر صفحات فروشگاه با شورتکدهای کلاسیک ساخته شده باشند، ممکن است بخش مهمی از عملیات از درخواستهای دیگری مانند ?wc-ajax=checkout استفاده کند.
مرحله 1 پیشنیازها و وضعیت فروشگاه را بررسی کنید
ابتدا از فایلها و پایگاه داده نسخه پشتیبان تهیه کرده و یک سایت آزمایشی مستقل ایجاد کنید. در پیشخوان به ووکامرس ← وضعیت ← وضعیت سیستم بروید و نسخه وردپرس، ووکامرس و PHP را ثبت کنید.
سپس از ووکامرس ← پیکربندی ← پیشرفته برگههای سبد خرید و تسویهحساب را کنترل کنید.
در محیط تست از درگاه پرداخت آزمایشی استفاده کنید و از ثبت سفارش واقعی با اطلاعات مشتریان پرهیز کنید.
مرحله 2 ساختار بلوکی یا کلاسیک سبد و پرداخت را مشخص کنید
در برگهها ← همه برگهها، صفحه سبد خرید را ویرایش کنید. اگر بلوک Cart نمایش داده میشود، صفحه بلوکی است؛ اما اگر شورتکد [woocommerce_cart] قرار دارد، از روش کلاسیک استفاده میکنید.
همین بررسی را برای برگه پرداخت انجام دهید: بلوک Checkout یا شورتکد [woocommerce_checkout].
این تفاوت اهمیت دارد، زیرا بعضی درگاهها یا افزونههای سفارشیسازی قدیمی با بلوکهای جدید سازگار نیستند. جابهجایی موقت میان حالت بلوکی و کلاسیک در محیط تست، فقط یک آزمایش برای شناسایی تداخل است و نباید بدون بررسی پیامدها روی فروشگاه اصلی انجام شود.
مرحله 3 خطا را بازتولید کنید
بهعنوان کاربر مهمان، یک محصول آزمایشی را به سبد اضافه کنید. تعداد آن را تغییر دهید، یک کد تخفیف آزمایشی وارد کنید و سپس به مرحله پرداخت بروید. اگر فقط یکی از این کارها خطا ایجاد میکند، همان اقدام را یادداشت کنید. زمان وقوع خطا و وضعیت ورود کاربر نیز اهمیت دارد.
اگر مشکل تنها بعد از چند دقیقه یا فقط برای کاربران مهمان رخ میدهد، احتمال اختلال در کش، نشست مشتری یا اعتبار توکن وجود دارد؛ اما این موارد باید با پاسخ درخواست تأیید شوند.
مرحله 4 درخواست مشکلدار را در مرورگر پیدا کنید
در مرورگر Chrome کلید F12 را بزنید و از بخش Network گزینه Fetch/XHR را انتخاب کنید. گزینه Preserve log را فعال کنید و همان اقدام مشکلدار را دوباره انجام دهید. در فهرست درخواستها عبارت store/v1 را جستجو کنید.
روی درخواست ناموفق کلیک کنید و Request URL، Request Method، Status Code و پیام غیرحساس بخش Response را بررسی کنید. اگر پاسخ JSON است، فیلدهای code و message معمولاً برای تشخیص علت مفیدند.
مقادیر Nonce، Cart-Token، Cookie، کلیدهای API و اطلاعات مشتری را در تصویر یا گزارش ارسالی مخفی کنید.
خطاهای 401 و 403 و 429 در Store API چه معنایی دارند؟
خطای 401 و اعتبارسنجی درخواست
خطای 401 میتواند به نبودن یا معتبر نبودن اطلاعات لازم برای درخواست مربوط باشد. در عملیات تغییر سبد و تسویهحساب، بررسی ارسال و بروزرسانی صحیح Nonce یا Cart Token اهمیت دارد. این خطا بهتنهایی اثبات نمیکند که فایروال درخواست را مسدود کرده است.
خطای 403 و رد درخواست
پاسخ 403 ممکن است از وردپرس، افزونه امنیتی، فایروال هاست یا یک سرویس CDN باشد. اگر بهجای پاسخ JSON یک صفحه HTML با پیام مسدودسازی دریافت میکنید، زمان درخواست را با گزارش رویدادهای امنیتی تطبیق دهید.
خطای 429 و محدودسازی نرخ درخواست
پاسخ 429 اغلب به محدودیت تعداد درخواستها مربوط است. ابتدا مشخص کنید محدودیت از سوی کدام لایه اعمال شده و چرا درخواست معمولی کاربر مشمول آن شده است. حذف کامل Rate Limiting راهحل مناسبی نیست.
خطای 500 یا پاسخ نامعتبر
گاهی پاسخ یک درخواست بهجای JSON، محتوای HTML، صفحه خطای PHP یا پاسخ کششده است. اگر کد وضعیت 500 باشد، باید لاگ PHP و سرور نیز بررسی شود. در این شرایط بدون شواهد نباید علت را به افزونه امنیتی نسبت داد.
مرحله 5 خطای Store API در صفحه پرداخت را جداگانه بررسی کنید
اگر سبد خرید درست کار میکند اما تسویهحساب خطا میدهد، درخواست مربوط به /checkout را در Network بررسی کنید. در فروشگاههای مبتنی بر بلوک، درگاه پرداخت یا ابزار ضدتقلب ممکن است به یکپارچهسازی ویژه با Store API نیاز داشته باشد. وضعیت سفارش آزمایشی را نیز پس از خطا بررسی کنید تا چند سفارش تکراری ایجاد نشود.
مرحله 6 گزارشهای ووکامرس و سرور را بخوانید
به ووکامرس ← وضعیت ← گزارشها بروید و گزارشهای مربوط به همان ساعت را بررسی کنید. ممکن است گزارشی با نام درگاه پرداخت یا افزونه مرتبط وجود داشته باشد. اگر گزارشی ثبت نشده، گزارش PHP، وبسرور یا امنیت هاست را بررسی کنید؛ همه خطاهای Store API لزوماً در گزارش ووکامرس دیده نمیشوند.
در گزارش قابل انتشار، نشانی و اطلاعات مشتری، کلیدهای محرمانه و اطلاعات حساس سفارش را حذف کنید.
مرحله 7 کش سبد خرید و پاسخهای پویا را اصلاح کنید
صفحات سبد خرید و پرداخت، محتوای وابسته به نشست مشتری دارند و نباید مانند صفحات عمومی در کش مشترک ذخیره شوند. تنظیمات افزونه کش، کش هاست و CDN را بررسی کنید تا صفحات پویا و پاسخهای شخصیسازیشده Store API بهاشتباه میان کاربران به اشتراک گذاشته نشوند.
پس از اصلاح قوانین کش، کش را پاک کرده و مشکل را در پنجره ناشناس مرورگر دوباره آزمایش کنید. مستثنا کردن یک پاسخ از کش با حذف کنترل امنیتی آن تفاوت دارد. هدف این است که داده پویا درست تحویل داده شود و اعتبارسنجی درخواست همچنان فعال باشد.
مرحله 8 قانون مسدودکننده را در فایروال پیدا کنید
اگر Response یا گزارش سرور نشان میدهد درخواست بهدلیل قانون امنیتی رد شده، بخش رویدادهای امنیتی را بررسی کنید. در Cloudflare میتوانید سراغ Security Events بروید؛ در Wordfence بخشهای مربوط به Firewall یا Live Traffic، در صورت فعال بودن، مفیدند. در بعضی هاستها بررسی گزارش ModSecurity از طریق پشتیبانی امکانپذیر است.
زمان، مسیر درخواست، متد، وضعیت پاسخ و شناسه قانون را با یکدیگر تطبیق دهید. اگر قانون مشخصی درخواست معتبر را به اشتباه رد میکند، از مسئول فنی بخواهید همان قانون را با استثنایی محدود اصلاح کند؛ نه اینکه تمام قوانین امنیتی را خاموش کند.
چرا خاموش کردن بررسی Nonce یا باز کردن کامل Store API اشتباه است؟
مستندات رسمی ووکامرس تأکید میکنند که درخواستهای مشخصی از Store API به Nonce معتبر یا Cart Token نیاز دارند. گرچه گزینهای برای غیرفعال کردن بررسی Nonce در محیط توسعه وجود دارد، استفاده از آن روی سایت عملیاتی توصیه نمیشود. مشکل واقعی ممکن است به کششدن توکن، تازهسازی نادرست آن یا ناسازگاری افزونه مربوط باشد.
همچنین قرار دادن کل مسیر /wp-json/wc/store/v1/ در فهرست مجاز بدون هیچ بررسی ممکن است محافظت سایت در برابر درخواستهای مخرب را کاهش دهد. اصلاح باید محدود، قابل بازگشت و بر اساس گزارش درخواست واقعی باشد.
مرحله 9 تداخل افزونههای پرداخت و قالب را بررسی کنید
اگر هیچ رویداد مسدودسازی در گزارش امنیتی وجود ندارد، سازگاری درگاه پرداخت، افزونه حملونقل، کپچا، ضدتقلب و ابزار سفارشیسازی پرداخت را با Cart and Checkout Blocks بررسی کنید. تست غیرفعالسازی افزونهها فقط در سایت آزمایشی انجام شود. برای آشنایی با روشهای تشخیص تداخل، آموزش غیرفعال کردن افزونههای وردپرس در همیار وردپرس نیز مفید است.
مرحله 10 نتیجه رفع مشکل را بدون کاهش امنیت تأیید کنید
پس از اصلاح، همان اقدام مشکلدار را دوباره در سبد خرید و تسویهحساب تکرار کنید. باید پاسخ درخواست درست باشد، تغییرات سبد ذخیره شوند و درگاه آزمایشی سفارش را مطابق انتظار ثبت کند. در پایان گزارش فایروال را بررسی کنید تا درخواست معتبر دوباره مسدود نشده باشد و کنترلهای امنیتی موردنیاز همچنان فعال بمانند.
چه زمانی باید به پشتیبانی هاست یا توسعهدهنده مراجعه کنیم؟
اگر مسدودسازی از ModSecurity یا فایروال میزبان ناشی میشود، گزارش درخواست را همراه با زمان و شناسه قانون به پشتیبانی بدهید و درخواست اصلاح محدود همان قانون را مطرح کنید. در مشکلات سازگاری افزونه، وضعیت نسخهها و پاسخ غیرحساس API را برای توسعهدهنده بفرستید. درخواست کلی برای باز کردن تمام REST API معمولاً راهحل دقیق و امنی نیست.
جمعبندی
برای رفع خطاهای Store API در سبد خرید و پرداخت ووکامرس، ابتدا مشخص کنید از صفحات بلوکی استفاده میکنید یا کلاسیک. سپس درخواست ناموفق را در Network پیدا کنید، پاسخ و گزارشهای مرتبط را بررسی کنید و علت واقعی را از میان اعتبارسنجی توکن، کش، تداخل افزونه یا قانون امنیتی تشخیص دهید. با اصلاح محدود و آزمایش دوباره میتوان عملکرد خرید را برگرداند، بدون اینکه امنیت فروشگاه خاموش شود.





