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