Turnstile לא מסתיים כשהרכיב מופיע: מאמתים כל שליחה מוגנת בשרת

הופעת רכיב Turnstile בטופס אינה מוכיחה שהטופס מוגן. תיעוד האימות בצד השרת של Cloudflare מחייב לבדוק את האסימון באמצעות Siteverify. אם האפליקציה מקבלת שליחה בלי הבדיקה הזאת, חוויה שנראית מוצלחת בדפדפן אינה יוצרת החלטה אמינה בשרת.

מטרת ההטמעה פשוטה: פעולה מוגנת אינה צריכה להתבצע רק משום שהדפדפן אומר שהבדיקה עברה. בנו ובדקו קודם את החלטת השרת, ואז חברו את הרכיב ואת מסלול ההתאוששות למשתמש. זהו תהליך מומלץ להטמעה ולאימות, ולא טענה ש-ClickSyrup בדק אפליקציה של אחד הקוראים.

עוקבים אחר האסימון מהדפדפן לשרת

מדריך ההתחלה מבדיל בין sitekey ציבורי למפתח secret פרטי. ה-sitekey שייך לחיבור בצד הלקוח; השרת משתמש בסוד לצורך האימות. אין לשים את המפתח הסודי בקוד הדפדפן, במאגר ציבורי או בקובץ תצורה גלוי למשתמש רק כדי לגרום לאב-טיפוס לעבוד.

כשהדפדפן שולח אסימון עם הטופס, העבירו אותו מהשרת לנקודת הקצה הקבועה של Siteverify, עם הסוד והאסימון כשדות הנדרשים. התייחסו לתשובה כאל נתונים שצריך לבדוק, לא כאל רשות שנובעת מעצם השלמת בקשת HTTP. האפליקציה צריכה את תוצאת האימות לפני ביצוע הפעולה המוגנת.

השאירו את הפעולה העסקית לאחר ההחלטה. שליחת מייל, יצירת רשומה או קבלת בקשה לפני בדיקת האסימון הופכות את סדר ההגנה. כתבו את הסדר במפורש במשימת הפיתוח, כדי שצוותי הלקוח והשרת לא יניחו כל אחד שהצד השני כבר אוכף אותו.

טפלו במכוון באסימון חסר, באסימון שנדחה ובמצב שבו אין תשובת אימות. אל תקבלו את הפעולה בשקט במקרים האלה. ספקו למבקרים לגיטימיים מסלול ניסיון חוזר ושמרו קלט מתאים שטרם נשלח, בלי לכלול מידע רגיש ביומני אבחון. אובדן הודעה ארוכה הוא בעיית חוויית משתמש שצריך לפתור, לא סיבה לדלג על אימות.

פקיעה ושימוש חוזר דורשים בדיקות משלהם

Cloudflare מתעדת תוקף של 300 שניות ואימות לשימוש יחיד. אסימון שפג תוקפו או שכבר אומת עשוי להחזיר timeout-or-duplicate. המשמעות המעשית היא שאסימון שהתקבל בפתיחת העמוד עלול להיות לא שמיש כשהמבקר מסיים טופס ארוך.

בדקו מילוי איטי ולא רק שליחה מיד לאחר הצלחת הרכיב. ודאו שהאפליקציה יכולה להשיג אסימון חדש ולאפשר ניסיון נוסף בלי לחזור במפתיע על הפעולה העסקית. המשתמש אינו צריך להבין את מנגנון האסימונים כדי להתאושש מעיכוב רגיל.

הפרידו שימוש חוזר באסימון מאידמפוטנטיות של הפעולה העסקית, כלומר מניעת ביצוע כפול שלה. אסימון תקף אינו מבטיח לבדו שהאפליקציה לא תיצור שתי רשומות זהות לאחר ניסיון רשת חוזר או לחיצה כפולה. במידת הצורך, תכננו את הפעולה כך שתזהה בקשות חוזרות שלה, ובדקו את ההתנהגות בנפרד מהרכיב.

כאשר השרת חוזר על קריאת אימות, השתמשו במנגנוני הניסיון החוזר והאידמפוטנטיות המתועדים של ה-API, במקום להניח שאפשר לאמת אותו אסימון ללא הגבלה. תעדו איזו שכבה חוזרת: שליחת הדפדפן, בקשת Siteverify או הפעולה העסקית. ערבוב בין השכבות מקשה להסביר כשלים שמופיעים לסירוגין.

בודקים את המארח והפעולה הצפויים, לא רק הצלחה

תשובת האימות כוללת שדות הקשר כגון hostname, וכאשר הוגדר, action. השוו אותם לערכים הצפויים שהאפליקציה מגדירה. אל תקבלו מארח או פעולה צפויים מאותה שליחת טופס לא מהימנה; כך הבקשה עצמה תקבע את הכלל שהיא אמורה לעמוד בו.

מדריך ניהול שמות המארח מסביר כיצד מאשרים מארחים לרכיב. הוא גם מציין שהוספת דומיין ראשי מאשרת את תת-הדומיינים שלו. בחרו את ההיקף במכוון ובדקו אותו במעבר מבדיקות לייצור. הגדרת הרכיב והבדיקה בשרת צריכות לתמוך בסביבה המיועדת, ולא לאשר בטעות סביבות אחרות.

Turnstile נשאר שכבה אחת. אימות זהות קובע מי המשתמש, הרשאות קובעות מה מותר לו לעשות, והאפליקציה עדיין צריכה בדיקת קלט ובקרות בקשות מתאימות. הצלחה באתגר אינה מצדיקה קבלת נתונים שרירותיים או מתן אפשרות למשתמש לפעול בחשבון של אדם אחר.

בדקו גם את מסלול אספקת העמוד. כאשר מעורב מטמון, הרחיקו תגובות ייחודיות לחשבון ומצב רגיש ממטמון משותף, לפי ההפרדה במדריך המטמון של Cloudflare. אתגר שפועל אינו מתקן כלל מטמון נפרד שחושף תוכן פרטי.

מוכיחים את מקרי הכשל לפני ההשקה

Cloudflare מספקת מפתחות והנחיות בדיקה למקרי הצלחה וכישלון מבוקרים. השתמשו בפרטי הבדיקה המתועדים בסביבת בדיקה מתאימה, ולא כהגנה בסביבת ייצור. מטרתם לאפשר בדיקות שחוזרות על עצמן בלי להיות תלויות בתוצאת אתגר אמיתי של מבקר.

צרו רישום קבלה שכולל שליחה תקפה, אסימון חסר, אימות שנכשל, אסימון שפג תוקפו, שימוש חוזר באסימון שכבר אומת ומארח או פעולה לא צפויים. בכל מקרה תעדו גם את תגובת המשתמש וגם אם השרת ביצע בפועל את הפעולה המוגנת. הודעה מרגיעה לבדה אינה מוכיחה ששום בקשה לא התקבלה.

הוסיפו לתוכנית הבדיקה הפרעה בשירות האימות וסכמו מראש מה המשתמש יראה. בדקו גם התאוששות כשהשירות חוזר. שלבו את הבדיקות בשגרת התחזוקה של האתר, במיוחד אחרי שינויים בטפסים, בשרתים מתווכים הפוכים, בסודות או בסביבת הפריסה.

תנאי ההשקה אינו צילום מסך של הרכיב. הוא תוצאה שאפשר לשחזר: בקשות מורשות מתבצעות פעם אחת כמתוכנן, בקשות שנדחו אינן מפעילות את הפעולה, הסודות נשארים בשרת ולמבקרים לגיטימיים יש דרך ברורה להתאושש. זה ההבדל בין הוספת רכיב נראה לעין לאכיפת הגנה.