حالت Bypass و بازیابی از اختلال
جریان Bypass در ARCaptcha از endpoint heartbeat برای تصمیم‌گیری درباره بارگذاری ویجت کپچا استفاده می‌کند. اگر heartbeat در دسترس نباشد، ویجت بارگذاری نمی‌شود. سپس backend شما سیاست مشخصی را برای اختلال اجرا می‌کند؛ عبور از کپچا یک تصمیم امنیتی در سطح برنامه است، نه تأیید کپچا.
۱. بررسی heartbeat آرکپچا
درخواست GET را به این آدرس ارسال کنید:
https://api.arcaptcha.ir/arcaptcha/api/heartbeat
پاسخ سالم شامل HTTP موفق و JSON برابر {"OK":true} است. خطای HTTP، timeout، خطای شبکه یا CORS، JSON نامعتبر یا هر پاسخی غیر از OK: true را heartbeat ناموفق در نظر بگیرید.
رفتار مرورگر
سرور به‌صورت دوره‌ای heartbeat را بررسی و آخرین نتیجه را cache می‌کند. خود سرور با این cache تصمیم می‌گیرد ویجت بارگذاری شود یا نه. دو روش برای ارائه تصمیم وجود دارد:
- برنامه با رندر سمت سرور: سرور فقط وقتی heartbeat cacheشده سالم است، اسکریپت ویجت را در HTML می‌گذارد؛ در غیر این صورت آن را حذف می‌کند.
- برنامه با رندر سمت کلاینت: کلاینت از backend مقدار
loadWidgetرا می‌گیرد و همان تصمیم را اجرا می‌کند. نمونه این تصمیم را ازGET /api/captcha/bootstrapمی‌دهد؛ کلاینت نباید مستقیماً با سرویس‌دهنده ارتباط بگیرد یا heartbeat خام را تفسیر کند.
وقتی سرور تصمیم می‌گیرد ویجت بارگذاری نشود، در SSR آن را از HTML حذف کنید یا در CSR مقدار loadWidget: false برگردانید. کپچای محلی یا token کپچا نسازید.
پروژه نمونه Node.js الگوی SSR را پیاده‌سازی و هر دو وضعیت heartbeat را شبیه‌سازی می‌کند. فایل src/server.js فقط در صورت سالم بودن heartbeat ویجت را رندر می‌کند؛ src/widget-view.js markup مناسب را می‌سازد و src/heartbeat.js endpoint را پایش می‌کند. مسیر /api/captcha/bootstrap تصمیم سرور را برای برنامه‌های CSR برمی‌گرداند. دمو به‌صورت پیش‌فرض اختلال heartbeat و سیاست fail-open را شبیه‌سازی می‌کند تا مسیر کامل Bypass دیده شود.
۲. روش بررسی دسترس‌پذیری در سرور
دمو از پایش دوره‌ای استفاده می‌کند: سرور heartbeat را در فاصله زمانی قابل تنظیم بررسی و آخرین وضعیت را در حافظه نگه می‌دارد. دروازه مرورگر و تصمیم backend هر دو همین مقدار cacheشده را می‌خوانند.
در چند نمونه production، وضعیت را در storage اشتراکی مانند Redis نگه دارید تا همه سرورها تصمیم یکسانی بگیرند. محدودیت تازگی تعریف کنید و وضعیت قدیمی را سالم فرض نکنید. بررسی هنگام درخواست جایگزینی است که تازگی بیشتری دارد ولی درخواست heartbeat بیشتری ایجاد می‌کند.
با npm start اجرا کنید؛ دمو به‌صورت پیش‌فرض اختلال heartbeat را شبیه‌سازی می‌کند. سیاست fail-open پیش‌فرض دمو فقط برای نمایش است؛ در production سیاست خود را انتخاب کنید و fail-closed را گزینه امن‌تر اولیه بدانید.
سرور تصمیم می‌گیرد ویجت بارگذاری شود یا نه. مرورگر فقط پاسخ loadWidget را اجرا می‌کند و heartbeat خام را به‌عنوان مجوز ارسال نمی‌کند. backend برای تأیید token یا اجرای سیاست اختلال از وضعیت heartbeat خودش استفاده می‌کند.
۳. تأیید token و اعمال سیاست اختلال
اگر token موجود است، آن را در سرور با POST https://api.arcaptcha.co/arcaptcha/api/verify و پارامترهای site_key، secret_key و challenge_id (مقدار arcaptcha-token ارسال‌شده) تأیید کنید.
- پاسخ
success: trueیعنی کپچا تأیید شده است. - پاسخ
success: falseیعنی token نامعتبر است و باید رد شود؛ حتی اگر fail-open فعال باشد. - خط ای شبکه، timeout و خطای موقت سرویس می‌توانند طبق سیاست اختلال برنامه مدیریت شوند.
| سیاست | هنگام در دسترس نبودن ARCaptcha | ملاحظه |
|---|---|---|
| Fail-closed (پیش‌فرض پیشنهادی) | درخواست محافظت‌شده را رد یا متوقف کنید. | اجرای کپچا حفظ می‌شود، اما ممکن است کاربر هنگام اختلال مسدود شود. |
| Fail-open (فعال‌سازی صریح) | درخواست را بدون token تأییدشده بپذیرید. | سرویس در دسترس می‌ماند، ولی ریسک سوءاستفاده خودکار بیشتر می‌شود. |
پاسخ قطعی token نامعتبر، نبود secret key سمت سرور یا خطای اتصال را به عبور از کپچا تبدیل نکنید. به flag سمت کلاینت مانند «heartbeat ناموفق بود» یا «کپچا قبول شد» به‌تنهایی اعتماد نکنید. تصمیم‌های Bypass را بدون token یا secret key ثبت کنید؛ محدودکردن fail-open به عملیات کم‌ریسک، rate limit و هشدار بر اساس حجم و مدت Bypass را در نظر بگیرید.
۴. آزمایش بازیابی پیش از production
این حالت‌ها را در محیط staging آزمایش کنید:
۱. Heartbeat سالم: مرورگر ویجت را بارگذاری کند، token معتبر تأیید شود و token نامعتبر رد شو د.
۲. Heartbeat ناموفق: مرورگر اسکریپت ویجت را درخواست نکند و token نسازد.
۳. Heartbeat سمت backend ناموفق: درخواست بدون token ارسال شود و سرور طبق سیاست fail-closed یا fail-open خودش تصمیم بگیرد.
۴. اختلال API تأیید پس از حل چالش: خطای شبکه یا سرویس موقت طبق سیاست مدیریت شود، ولی success: false همچنان رد شود.
۵. بازیابی: heartbeat را برگردانید و مطمئن شوید بارگذاری کپچا و تأیید عادی بدون reset دستی از سر گرفته می‌شود.
پروژه نمونه Node.js شامل دروازه کلاینت، پایش دوره‌ای heartbeat، تأیید سمت سرور، سیاست اختلال و شبیه‌سازی heartbeat ناموفق است.