פיתוח אימות באמצעות מספר טלפון עם קוד SMS

אימות SMS באפליקציית מובייל: היכן הכניסה נשברת

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

הסוג הראשון של תקלות — קוד שלא נמסר. הודעה יכולה להיתקע בצד האגרגטור, להיחסם על ידי מסנן של המפעיל הסלולרי או ללכת לאיבוד במעבר מ-Wi-Fi לרשת סלולרית. אם הלוגיקה לא מבחינה בין הסטטוסים «נשלח» ו«נמסר», האפליקציה מציגה אישור שגוי ואינה מאפשרת לנסות שוב.

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

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

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

מה נותנת כניסה מנוהלת באמצעות קוד: זמנים ואמינות

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

כאשר הקוד מוזן אוטומטית לשדה מתוך ההודעה הנכנסת, אין צורך למזער את האפליקציה ולהקליד את הספרות ידנית — בזרימה המונית זה מעלה את שיעור הכניסות שהושלמו מ-65–75% ל-90%+, והזמן מבקשת הקוד ועד הכניסה עומד על 15–25 שניות.

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

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

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

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

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

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

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

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

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

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

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

1. ביקורת תרחיש הכניסה. מפרקים מסכים, מצבים ושגיאות: מה מציגים בפסק זמן, מה בקוד שגוי, לאן מחזירים לאחר ביטול. מקבעים דרישות — אורך הקוד, זמן החיים, מספר הניסיונות, ההתנהגות בעת החלפת מספר במכשיר עם שני SIM.
2. תרשים זרימות האימות. משרטטים מסלולים: כניסה ראשונה, חוזרת, החלפת מכשיר, שחזור גישה. בנפרד — אפשרויות גיבוי: מילוי אוטומטי מההתראה במערכת, שליחה חוזרת, ערוץ מסירה חלופי.
3. הגדרת שליחת הקודים. מחברים ספקים, מפזרים את התעבורה, קובעים מגבלות על מספר, מכשיר וכתובת, מגדירים תבניות וכללי מעבר בעת אי-מסירה.
4. בדיקה בסביבת בדיקות. מריצים תרחישי ביטול, חסימה, פקיעת תוקף הקוד, הזנה ידנית ועבודה ללא רשת, ומצליבים סטטוסי מסירה בצד האפליקציה ובצד השער.
5. בדיקת עומסים של הכניסה. מזרימים זרם שיא של הרשמות, מודדים את זמן התגובה של השירות, את שיעור ההודעות שנמסרו ואת התנהגות התור בעת השהיה של המפעיל. כאן גם מכיילים את המגבלות, כדי שמשתמשים לגיטימיים לא ייתקלו בהגנה מפני ניחוש.
6. קבלה ומסירה. מוסרים את תרשים הזרימות, את תצורת המגבלות, מספרי בדיקה ורשימת בדיקות לפני שחרור, ומדגימים לצוות הלקוח ניתוח תקלות לפי היומנים.

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

מה אנו מוסרים לידיים: הגדרות, תרשימים, נהלים

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

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

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

מקרה בוחן: צמצמנו פי שלושה את שיעור הכניסות הכושלות

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

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

מה שינינו

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

שיעור האימותים המוצלחים של המספר עלה מ-62% ל-91%. הזמן עד הכניסה לאפליקציה הצטמצם מ-45 ל-9 שניות במכשיר ממוצע. בקשות חוזרות לקוד ירדו בחצי, ופניות לתמיכה בנושא כניסה — מ-14% ל-4% ממספר הכניסות.

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

מדוע קוד SMS לא מגיע: אבחון תקלות נפוצות

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

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

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

שאלות נפוצות: מגבלות, אבטחה, תמיכה

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

אילו מגבלות יש על שליחת הודעות?

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

מה קורה בעת החלפת מספר טלפון?

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

האם אפשר להיכנס מכמה מכשירים?

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

מה עם התמיכה לאחר היישום?

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

נדון במשימה ונחזור עם תוכנית ואומדן

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

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

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

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