תפריט

בדיקת אימות דואר אלקטרוני: תהליכים שנשברים בשקט

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

פורסם

  • תהליכי בדיקה
  • אימות
  • סביבת בדיקות

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

המצבים שתהליך אימות עובר בהם

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

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

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

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

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

מה נשבר כשקישור אימות נפתח פעמיים?

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

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

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

בדיקת נתיבי שינוי הכתובת והאיפוס

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

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

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

מה צריך לקרות כשהדואר לא מגיע?

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

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

קריאת קוד מתיבת דואר חד-פעמית

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

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

למפתחים: אסימונים, אידמפוטנטיות והנתיב הלא שמח

יש למדל את האסימון, לא רק את הטופס. שלוש תכונות ראויות לכיסוי מפורש.

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

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

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

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

צעדים הבאים

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

המשך קריאה

מדריכים בנושא דואר זמני (דואר חד-פעמי / דואר 10 דקות)