آموزش Cloudflare Turnstile در وردپرس؛ محافظت از فرم‌ها و آزمون اعتبارسنجی
Turnstile را برای فرم‌های ورود، دیدگاه و تماس وردپرس راه‌اندازی کنید؛ تفاوت کلید عمومی و محرمانه، آزمون ارسال واقعی، خطاهای رایج و شرط حیاتی اعتبارسنجی سمت سرور را بشناسید.
اگر فرم تماس یا صفحه ورود وردپرس شما درخواست‌های ناخواسته دریافت می‌کند، Cloudflare Turnstile می‌تواند یک لایه تشخیص درخواست انسانی به جریان ارسال اضافه کند. اما یک سوءتفاهم مهم وجود دارد: دیده‌شدن ویجت روی صفحه، به‌تنهایی به معنی محافظت از نقطه دریافت فرم نیست. توکن ایجادشده در مرورگر باید هنگام هر ارسال در سرور اعتبارسنجی شود. در این راهنما مسیر راه‌اندازی برای مدیر وردپرس، روش آزمون درست و خطاهایی را که معمولاً پس از نصب پنهان می‌مانند، قدم‌به‌قدم بررسی می‌کنیم.
سناریوی ما یک سایت وردپرسی با فرم ورود، دیدگاه‌ها و یک فرم تماس است. می‌خواهیم ابتدا فقط فرم کم‌ریسک را در محیط آزمایشی فعال کنیم؛ سپس ارسال معمولی و درخواست نامعتبر را بررسی کنیم. این مقاله راهنمای تغییر تنظیمات سایت خودتان است، نه ادعای اینکه روی همه قالب‌ها و افزونه‌ها رفتار یکسانی مشاهده می‌شود. نام منوها و سازگاری را با نسخه نصب‌شده تطبیق دهید.
Turnstile دقیقاً کدام بخش فرم را پوشش می‌دهد؟
مطابق راهنمای شروع Cloudflare، ویجت سمت مرورگر توکن می‌سازد و سرور باید همان توکن را با Siteverify بررسی کند. Sitekey شناسه عمومی ویجت است و برای نمایش آن در صفحه استفاده می‌شود؛ secret اعتبارنامه خصوصیِ اعتبارسنجی سمت سرور است. این دو را جابه‌جا نکنید و secret را در HTML، فایل جاوااسکریپت عمومی، تصویر آموزشی یا مخزن منتشرشده نگذارید.
Turnstile لزوماً نیازمند عبور کل سایت از پراکسی Cloudflare نیست؛ خود سرویس می‌تواند مستقل به کار رود. در عین حال جایگزین همه تدابیر امنیتی نیست: محدودکردن نرخ درخواست، به‌روزرسانی افزونه‌ها، مدیریت دسترسی و بررسی پیام‌های ورودی هنوز اهمیت دارند. اگر فرم‌ساز شما اعتبارسنجی سمت سرور را انجام نمی‌دهد، اضافه‌کردن ظاهر ویجت به‌تنهایی نقص را برطرف نمی‌کند.
پیش‌نیازها را پیش از تغییر سایت آماده کنید
- دسترسی مدیریتی به وردپرس و حساب Cloudflare برای ساخت ویجت داشته باشید؛ برای آزمون اولیه، یک محیط آزمایشی یا نسخه پشتیبان قابل بازگردانی فراهم کنید.
- فهرست فرم‌هایی را که واقعاً فعال‌اند بنویسید: ورود، ثبت‌نام، دیدگاه، تماس، پرداخت یا فرم‌سازهای دیگر. حضور یک فرم در سایت به معنی پشتیبانی خودکار افزونه از آن نیست.
- دامنه‌ای را که بازدیدکننده روی آن فرم را باز می‌کند، دقیق ثبت کنید. تفاوت دامنه اصلی و زیر‌دامنه آزمایشی می‌تواند در تنظیم hostname اثر بگذارد.
- اگر روی سایت زنده کار می‌کنید، زمان کم‌ترافیک و مسیر بازگشت را مشخص کنید. قفل‌شدن تصادفی فرم ورود یا پرداخت باید سریع قابل رفع باشد.
برای آماده‌سازی محیط آزمایشی، پشتیبان و مسیر بازگشت می‌توانید از چک‌لیست آزمون و بازگشت امن وردپرس نیز کمک بگیرید؛ موضوع آن ارتقای وردپرس است، اما اصل تفکیک آزمون از Production اینجا هم کاربرد دارد.
گام اول: ویجت و کلیدها را در Cloudflare بسازید
در داشبورد Cloudflare به بخش Turnstile بروید و Add widget را انتخاب کنید. یک نام توصیفی مثل «فرم‌های سایت» بگذارید؛ دامنه یا دامنه‌های مجاز همان جایی باشند که ویجت قرار است بارگذاری شود. حالت ویجت را با نیاز تجربه کاربری خود انتخاب کنید و تنظیمات را ذخیره کنید. طبق مستند ساخت ویجت، پس از ساخت، sitekey و secret را دریافت می‌کنید.
این کلیدها را همان لحظه در جای امن نگه دارید. sitekey برای تنظیم سمت نمایش است و secret فقط باید به افزونه یا کد سمت سرورِ مورد اعتماد داده شود. اگر محیط آزمایشی دامنه جداگانه دارد، برای آن پیکربندی جدا بسازید تا اشتباه در hostname یا جابه‌جایی کلیدهای آزمون و تولید به سایت اصلی سرایت نکند. کلید واقعی را در گزارش خطا، اسکرین‌شات عمومی یا گفت‌وگوهای پشتیبانی قرار ندهید.
کدام hostname را اضافه کنم؟
نشانی‌ای را در نظر بگیرید که مرورگر کاربر روی آن ویجت را اجرا می‌کند، نه صرفاً نام پنل مدیریت یا آدرس سرور میزبان. برای مثال، اگر فرم از یک زیر‌دامنه جدا ارائه می‌شود، همان زیر‌دامنه باید در تنظیمات مجاز ویجت لحاظ شود. هنگام آزمون، خطای نمایش ویجت را با دامنه صفحه و تنظیم hostname مقایسه کنید؛ به جای افزودن بی‌حساب دامنه‌ها، فقط موارد مورد نیاز و تحت کنترل خودتان را مجاز کنید.
گام دوم: افزونه و فرم‌های هدف را تنظیم کنید
یک راه بدون کدنویسی، استفاده از افزونه‌ای است که هم نمایش ویجت و هم مسیر اعتبارسنجی را برای فرم مورد نظر پیاده‌سازی کرده باشد. برای مثال، صفحه رسمی Simple CAPTCHA with Cloudflare Turnstile در WordPress.org فرم‌های پیش‌فرض وردپرس، چند فرم ووکامرس و شماری از فرم‌سازها را فهرست کرده است. پیش از نصب، سازگاری نسخه فعلی افزونه را با فرم‌ساز، نسخه وردپرس و جریان پرداخت خود در همان صفحه بررسی کنید. این مثال تنها یک مسیر اجرایی است، نه تأیید همه افزونه‌ها یا تضمین حذف کامل اسپم.
- در محیط آزمایشی، افزونه را از مخزن رسمی وردپرس نصب و فعال کنید. اگر افزونه مشابه دیگری فعال است، تنظیمات تداخلی را پیش از آزمون شناسایی کنید.
- به Settings → Cloudflare Turnstile بروید و sitekey و secret مربوط به همان محیط را در فیلدهای مشخص وارد کنید. secret را در متن صفحه عمومی یا کد قالب کپی نکنید.
- در آغاز فقط یک فرم کم‌ریسک، مثلاً دیدگاه یا تماس، را انتخاب کنید. تنظیمات را با Save Changes ذخیره کنید.
- دکمه TEST API RESPONSE را در تنظیمات افزونه اجرا کنید و نتیجه را بررسی کنید. موفقیت این دکمه جای آزمون خود فرم را نمی‌گیرد؛ فقط بخشی از اتصال را می‌سنجد.
- فرم را در پنجره خصوصی، بدون نشست مدیر، باز کنید. بارگذاری ویجت، امکان ارسال عادی و رسیدن نتیجه به مقصد مورد انتظار را بررسی کنید.
اگر از Contact Form 7، WPForms یا فرم‌ساز دیگری استفاده می‌کنید، قبل از فعال‌سازی مطمئن شوید نسخه نصب‌شده‌تان در فهرست فرم‌های پشتیبانی‌شده است. سپس همان فرم واقعی را جداگانه بیازمایید. ممکن است فرم پیش‌فرض ورود سالم باشد، اما فرم ساخته‌شده با افزونه دیگر مسیر متفاوتی داشته باشد. برای فرم پرداخت، آزمون را با سفارش آزمایشی و بدون تراکنش واقعی انجام دهید.
گام سوم: حفاظت واقعی را با سناریوی موفق و ناموفق بسنجید
آزمون خوب فقط دیدن کادر Turnstile نیست. یک بار فرم را به‌صورت کاربر عادی با داده بی‌خطر پر کنید؛ اگر ارسال موفق بود، پیام سمت کاربر و ثبت مقصد را بررسی کنید. سپس یک حالت نامعتبر را در محیط آزمایشی بیازمایید: نبود توکن، خطای اعتبارسنجی یا توکن مصرف‌شده باید به ردِ درخواست و پیام قابل‌فهم منجر شود، نه ثبت پنهانی پیام یا دیدگاه. برای آزمایش‌های خودکار یا توسعه سفارشی، کلیدهای آزمایشی رسمی Cloudflare جریان موفق و ناموفق قابل‌پیش‌بینی فراهم می‌کنند؛ کلیدهای آزمایشی را با کلید Production مخلوط نکنید.
چرا این آزمون ضروری است؟ Cloudflare در مستند Siteverify تصریح می‌کند که اعتبارسنجی سمت سرور اجباری است. توکن تنها پنج دقیقه اعتبار دارد و یک‌بارمصرف است. اگر کاربر فرم را مدت طولانی باز بگذارد یا همان ارسال را دوباره تکرار کند، خطای انقضا یا مصرف مجدد می‌تواند رخ دهد. بنابراین در آزمون، پیام مناسب برای تلاش دوباره و تولید توکن تازه را هم بررسی کنید.
نشانه‌های نتیجه درست چیست؟
- درخواست معتبر: فرم پس از تأیید سرور پذیرفته می‌شود و فقط یک بار نتیجه مطلوب، مثل پیام تماس آزمایشی، ثبت می‌شود.
- درخواست بدون تأیید: دریافت‌کننده فرم آن را رد می‌کند؛ صرفاً مخفی شدن دکمه ارسال در مرورگر کنترل امنیتی نیست.
- توکن منقضی یا تکراری: کاربر می‌تواند بدون افشای جزئیات فنی، فرم را تازه‌سازی یا دوباره امتحان کند؛ درخواست نامعتبر نباید موفق ثبت شود.
- خطای سرویس یا تنظیم: رفتار شکست افزونه و پیام سمت کاربر را بدانید. اگر افزونه حالت failsafe دارد، تصمیم پذیرش یا رد در اختلال را آگاهانه و متناسب با ریسک فرم بگیرید.
در پیاده‌سازی سفارشی، نتیجه Siteverify تنها یک پاسخ ظاهری نیست: سرور باید مقدار success را کنترل کند و در صورت استفاده از hostname یا action، آن‌ها را با انتظار برنامه تطبیق دهد. این بخش به توسعه‌دهنده سمت سرور مربوط است. در مسیر افزونه‌ای، از مستندات و رفتار واقعی همان افزونه اطمینان بگیرید؛ فرض نکنید هر پلاگین تمام این بررسی‌ها را یکسان انجام می‌دهد.
وقتی ویجت دیده نمی‌شود یا فرم قفل می‌شود، از کجا شروع کنیم؟
نخست خطا را به یکی از سه مرحله جدا کنید: بارگذاری ویجت در مرورگر، ارسال توکن با فرم، یا بررسی توکن در سرور. این تفکیک جلوی تغییرهای تصادفی و هم‌زمان را می‌گیرد. اگر ویجت اصلاً ظاهر نمی‌شود، صفحه را در پنجره خصوصی و روی دامنه درست باز کنید، کلید عمومی و hostname را با داشبورد تطبیق دهید و تداخل احتمالی قالب، افزونه کش یا ابزار مسدودکننده اسکریپت را بررسی کنید. اگر ویجت هست ولی ارسال همیشه ناموفق است، کلید محرمانه همان ویجت، نتیجه TEST API RESPONSE و گزارش خطای افزونه را بررسی کنید؛ مقدار secret را در خروجی عمومی ثبت نکنید.
اگر فقط یک فرم مشکل دارد، پشتیبانی همان فرم را دوباره با صفحه رسمی افزونه تطبیق دهید. برای مثال، فعال‌شدن Turnstile روی فرم ورود دلیل کافی برای فعال‌بودن آن روی فرم تماس ساخته‌شده با افزونه دیگر نیست. اگر پس از فعال‌سازی، ورود مدیر مختل شد، از دسترسی مدیریتی جایگزین یا مسیر بازگشت از پیش آماده‌شده استفاده کنید و آخرین تغییر را در محیط آزمایشی تکرار کنید. چند تنظیم را یک‌باره عوض نکنید؛ پس از هر تغییر محدود، همان سناریوی شکست را دوباره اجرا کنید.
چک‌لیست پیش از انتقال به سایت اصلی
- فرم‌های هدف و فرم‌سازهای نصب‌شده با فهرست پشتیبانی افزونه تطبیق داده شده‌اند.
- دامنه یا زیر‌دامنه واقعی در پیکربندی ویجت قرار دارد و کلیدهای محیط آزمون و تولید جدا هستند.
- secret در صفحه عمومی یا مخزن دیده نمی‌شود و دسترسی تنظیمات آن محدود است.
- درخواست معتبر از پنجره خصوصی پذیرفته و درخواست نامعتبر واقعاً در سمت سرور رد می‌شود.
- رفتار فرم پس از انقضای توکن و هنگام خطای سرویس روشن است.
- برای فرم ورود و پرداخت، راه بازگشت و آزمون بدون تراکنش واقعی آماده است.
- پس از انتقال، نمونه‌ای از هر فرم هدف روی موبایل و دسکتاپ و با یک نشست مهمان بررسی می‌شود.
پرسش‌های متداول
آیا نمایش ویجت یعنی فرم محافظت شده است؟
خیر. سرور باید توکن هر ارسال را با Siteverify بررسی کند و بر اساس نتیجه، درخواست را بپذیرد یا رد کند. ویجت فقط بخش سمت مرورگرِ این جریان است.
sitekey و secret چه تفاوتی دارند؟
sitekey شناسه عمومی برای نمایش ویجت است. secret اعتبارنامه خصوصیِ بررسی توکن در سرور است؛ قرار دادن آن در HTML یا جاوااسکریپت عمومی، محرمانگی را از بین می‌برد.
چرا همان فرم چند دقیقه بعد خطا می‌دهد؟
توکن Turnstile محدودیت زمانی و مصرف یک‌باره دارد. صفحه یا ویجت را برای دریافت توکن تازه بارگذاری کنید و اگر مشکل تکرار شد، کلیدها، hostname و پاسخ اعتبارسنجی را بررسی کنید.
آیا یک افزونه همه فرم‌های وردپرس را پوشش می‌دهد؟
خیر. فهرست فرم‌های پشتیبانی‌شده را در صفحه نسخه فعلی افزونه ببینید و برای هر فرم واقعی، آزمون موفق و ناموفق جداگانه اجرا کنید.
جمع‌بندی و گام بعدی
برای راه‌اندازی قابل‌اعتماد Turnstile، سه حلقه باید با هم کار کنند: ویجت در دامنه درست، توکن همراه فرم، و تصمیم سمت سرور پس از Siteverify. مسیر عملی از ساخت ویجت و نگهداری امن کلیدها شروع می‌شود، با فعال‌سازی محدود یک فرم ادامه پیدا می‌کند و با آزمونِ پذیرش درخواست معتبر و ردِ درخواست نامعتبر کامل می‌شود. این ترتیب از انتشار تنظیماتی که فقط ظاهر محافظت دارند، جلوگیری می‌کند.
ابتدا یک فرم کم‌ریسک را در محیط آزمایشی فعال کنید، ارسال موفق و ردِ درخواست نامعتبر را بیازمایید و فقط پس از ثبت مسیر بازگشت، تنظیمات را به فرم‌های اصلی ببرید.