אימות דרך TON Connect: היכן נשברת הכניסה לאפליקציה
כניסה דרך ארנק נראית כמו החלפה פשוטה: האפליקציה יוצרת בקשה, הארנק מחזיר כתובת וחתימה, והשרת מנפיק סשן. בדרך כלל זה נשבר לא בקריפטוגרפיה, אלא בנקודות החיבור — כאשר תשובת TON Connect מגיעה בערוץ לא זה שהממשק מצפה לו.
תוסף הדפדפן משיב בתוך העמוד, ארנק נייד — בחזרה דרך קישור, והדפדפן המוטמע בארנק — בלי מעבר כלל. תשובת ארנק לא מטופלת בכל אחד מהנתיבים האלה נותנת סימפטום אחד: החתימה כבר ניתנה, אבל המשתמש רואה שגיאת אימות ולוחץ שוב על «חבר ארנק».
אובדן סשן — נקודה שקטה שנייה. כל עוד הלשונית פתוחה, מצב החיבור חי בזיכרון, אבל אחרי רענון או חזרה מרקע בטלפון הוא נעלם, בעוד שבשרת מפתח הסשן עדיין תקף. חיבור ארנק חוזר לאפליקציה באותו רגע או נתקל בסשן תפוס, או יוצר כפילויות של שיוכים.
אזור נפרד — חתימת הבקשה: תוקף המטען השימושי, קישור לדומיין, בדיקת הכתובת בשרת. בדיקה חלקית יוצרת סירובים שגויים בזמן אישור איטי וקולטת חתימה שהונפקה לאפליקציה אחרת. בהמשך נסביר איך סוגרים את הנקודות האלה באמצעות סכימה, ולא בטלאים בממשק.
מה משתנה אחרי ההטמעה: מהירות כניסה ושיעור סשנים מוצלחים
כניסה שנבנתה בקפידה דרך TON Connect מסירה שלבים ביניים: אין צורך להמציא סיסמה, לחכות למכתב ולהזין קוד. נשארות שתי פעולות — לחבר ארנק ולחתום על הודעה. זמן האימות מפסיק להיות תלוי בעיכובי דואר ונמדד בשניות, לא בדקות.
המדד המרכזי כאן — שיעור הכניסות המוצלחות. כל מסך מיותר איבד חלק מהקהל, והנשירה העיקרית הייתה באישור: המשתמש סגר את הארנק, חזר ללשונית הלא נכונה, או שהחתימה לא תאמה לכתובת הצפויה.
אנחנו מטפלים בחזרה לאפליקציה ובבקשה שפג תוקפה באופן מפורש — עם הודעה ברורה וניסיון חוזר, ולא עם מסך ריק.
גם סוג הסירובים עצמו משתנה. במקום סט של «המכתב לא הגיע», «הקוד פג», «הסיסמה נשכחה» נשאר תרחיש צפוי אחד — המשתמש דחה את החתימה. זו פעולה מודעת, לא תקלת תשתית, ולכן התמיכה מפסיקה לטפל בפניות חוזרות על אותו דבר.
יציבות הסשנים נשענת על בדיקת החתימה בשרת ותוקף אסימון הגישה: הסשן מתארך בלי אישור חוזר בארנק, מבוטל בעת ניתוק הכתובת, ועובר כראוי החלפת חשבון בארנק. הכניסה הופכת לצפויה: שיעור הניסיונות המוצלחים עולה, ומספר הפניות בנושא גישות יורד.
דרכי חיבור ארנק: השוואת מצבים ומגבלות
מצב החיבור קובע לא רק איך המשתמש נכנס לאפליקציה, אלא גם מה יהיה צריך לעשות בכל פעולה משמעותית: לחתום מחדש או לעשות שימוש חוזר בסשן קבוע. מזה תלויים שיעור המגיעים לכניסה, היקף הלוגיקה בצד הממשק ומספר נקודות הכשל בין הארנק לחלק השרת.
בפועל הבחירה מצטמצמת לחמישה תרחישים — מתוסף בדפדפן ועד סכימה היברידית, שבה ארנק נייד משלים את גרסת השולחן. להלן השוואה לפי תאימות ומגבלות של דרך הכניסה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תוסף בדפדפן | תרחיש שולחני, קהל עם ארנק מותקן | לא עובד בסמארטפונים, דורש התקנה ועדכון של התוסף |
| ארנק נייד לפי קוד או קישור | עיקר התעבורה מסמארטפונים | החזרה לאפליקציה תלויה בפלטפורמה, חלק מהמשתמשים הולכים לאיבוד במעבר |
| שירות מתווך חיצוני | נדרשת כניסה למי שאין לו עדיין ארנק | מופיע צד מהימן, והשליטה במפתחות מצטמצמת |
| בדיקת חתימה חד-פעמית | אישור בעלות על כתובת, כניסה לאזור אישי | אין סשן קבוע — בכל פעולה החתימה מתבקשת מחדש |
| סכימה היברידית | מוצר המוני עם סוגי מכשירים שונים | לוגיקת ביטול הסשן וטיפול בשגיאות מורכבים במידה ניכרת |
בנפרד אנחנו מתכננים את מה שבדרך כלל צף כבר בפרודקשן: התנהגות בעת ביטול גישה, החלפת מכשיר וחיבור חוזר. סשן קבוע צריך להסתיים באופן צפוי, ובדיקת חתימה חד-פעמית — לא לדרוש אישורים מיותרים במקומות שבהם הם לא נחוצים.
שלבי ההטמעה: מסכימת זרימות ועד מסירת נהלים
מתחילים בניתוח תרחישים: איך המשתמש נכנס מהמחשב ומהטלפון, אילו תפקידים משתתפים, איזה נתונים צריכים להיות בסשן. בסיכום מקבעים את סכימת האימות — מבקשת חיבור הארנק ועד הנפקת סשן בשרת — ורק אחר כך עוברים לקוד. את הסכימה בונים על TON Connect, כי זה תקן לחיבור ארנקים, ולא החלפת מפתחות בהתאמה עצמית.
- ניתוח תרחישי כניסה. אוספים נתיבים אמיתיים: דפדפן עם תוסף ארנק, אפליקציה ניידת, מעבר לפי קוד QR. בנפרד מפרטים את ההתנהגות כשהמשתמש סגר את חלון האישור או התחבר בכתובת אחרת.
- סכימת אימות. מתארים רצף שלבים: בקשת חיבור, יצירת מטען שימושי, חתימה בצד הארנק, בדיקה בשרת, הנפקת סשן וקישור הכתובת לחשבון.
- הגדרת האינטגרציה. ממלאים מניפסט, מגדירים רשימת ארנקים נתמכים, תוקף חתימה וסשן, כללי טיפול בסירוב ובחיבור חוזר.
- סביבת בדיקות. פורסים סביבה מבודדת עם רשת בדיקות, כדי להריץ כניסות בלי לפגוע בארנקים אמיתיים ובנתוני עבודה.
- סדר הבדיקות. עוברים על סט מקרים: כניסה מוצלחת, סירוב לחתום, שימוש חוזר באותה חתימה, סשן שפג, החלפת כתובת. כל מקרה סוגרים בבדיקה בשרת, ולא רק בצד הממשק.
- מסירת הפתרון. מוסרים נהלים, סכימות זרימות, תיאור גישות ותיעוד לוגים, מלמדים את הצוות ומלווים את תקופת ההפעלה הראשונה.
מה נשאר לצוות: תצורות, סכימות ונהלי גישה
האינטגרציה לא מסתיימת בכפתור כניסה שעובד: חשוב שאחרי הקבלה יישארו לצוות ארטיפקטים שבאמצעותם כל מהנדס יריץ סביבה, יטפל בפנייה ויוסיף דרך כניסה חדשה בלי לקרוא את כל בסיס הקוד. אנחנו אוספים אותם תוך כדי העבודה, ולא «נכתוב אחר כך», ומוסרים יחד עם קוד המקור.
- סביבות מוגדרות — סביבת בדיקות וסביבת עבודה עם תיאור כתובות הצמתים, משתני חיבור, מקום אחסון המפתחות וכללי מילוי קובץ המניפסט שלפיו הארנק מזהה את האפליקציה.
- סכימות זרימות אימות — הנתיב מלחיצה על כפתור בממשק ועד הנפקת סשן: יצירת הודעה, בדיקת חתימה בצד השירות, קישור כתובת הארנק לחשבון וטיפול בכניסה חוזרת.
- מטריצת תפקידים — מי מהעובדים קורא לוגים של חיבורים, מי משנה את רשימת הארנקים הנתמכים והדומיינים, מי מבטל סשנים פעילים.
- מדיניות גישה — תוקף ההודעה החתומה והסשן, סדר החלפת מפתחות, פעולות בעת חשיפת ארנק או החלפת בעלים.
- תיעוד אימות — דרישות לחתימה, טבלת קודי שגיאה ומה שהמשתמש רואה בכל שלב, מגבלות לפי דומיין.
- סט בדיקות — בדיקות חתימה ושימוש חוזר בהודעה, תרחישי סירוב לחתום וניתוק קשר, בדיקת ביטול סשן.
- נוהל תמיכה — אילו נתונים לאסוף לפנייה «הכניסה לא עוברת», איך להבדיל בין בעיית ארנק לבעיית שירות ובאיזה זמן אנחנו נותנים מענה.
כל סעיף אנחנו מכניסים לאותו מאגר קוד, עם סימון האחראי, כדי שכעבור חצי שנה שינויים בלוגיקת הכניסה לא יסתרו את התיעוד.
מקרה בוחן: איך כניסה דרך ארנק הפסיקה לאבד משתמשים
לפני: הכניסה הלכה לאיבוד באמצע הדרך
הפרויקט — מרקטפלייס של מוצרים דיגיטליים עם אימות דרך ארנק. בתחילה הכניסה נבנתה על קריאות ישירות לספק: החתימה נבדקה בצד הלקוח, מצב החיבור חי בזיכרון הלשונית, ובמקרה של סירוב לאשר המשתמש חזר למסך ריק והתחיל מהתחלה.
ניתחנו את המשפך לפי הלוגים. מבין אלה שלחצו על «חבר ארנק», עד סשן מאושר הגיעו 63%. כל ביקור שלישי לווה בניסיון כניסה חוזר: אנשים סגרו את חלון הארנק כשרשת לא תאמה, והאפליקציה לא הודיעה מה בדיוק השתבש. שחזור סשן אחרי רענון עמוד דרש חזרה ידנית על כל השרשרת — בממוצע ארבע פעולות ברצף.
אחרי: שרשרת אחת עם מצבים מפורשים
את TON Connect בנינו מחדש כנקודת כניסה יחידה: בדיקת החתימה עברה לשרת, מצב החיבור נשמר עם קישור למפתח הסשן, ולכל כשל יש מסך משלו — «הארנק לא מותקן», «הרשת לא תואמת», «החתימה נדחתה». חזרה מכל סירוב מובילה לאותו שלב, ולא לתחילת התרחיש.
שיעור הכניסות שהושלמו עלה מ-63% ל-91%, והניסיונות החוזרים קטנו כמעט פי שלושה. הסשן משוחזר אוטומטית אחרי רענון — פעולה אחת של המשתמש במקום ארבע, בלי אישור חוזר בארנק. פניות לתמיכה בנושא כניסה ירדו לכמה בודדות בשבוע, ומקרה האינטגרציה עצמו הפך לתבנית לשאר השירותים של הלקוח.
במה TON Connect שונה מחתימת הודעה עצמאית?
שתי הגישות פותרות משימה אחת — להוכיח לאפליקציה שהמשתמש מחזיק במפתח. TON Connect הוא חיבור ארנק מוכן: התקן כבר מתאר את ההחלפה, החתימה ומחזור החיים של הסשן. בדיקת חתימה עצמאית משמעה שאנחנו בונים את כל ההחלפה הזו בעצמנו, מיצירת הבקשה ועד פענוח התשובה.
ההבדל מתגלה לא בהתחלה, אלא לאורך הדרך.
| קריטריון | TON Connect | בדיקת חתימה עצמאית |
|---|---|---|
| תאימות ארנקים | תקן אחיד — ארנק חדש מתחבר בלי התאמות | כל ארנק דורש ענף נפרד לפענוח התשובה |
| תמיכה בפתרון | שינויים בתקן מטופלים על ידי הקהילה | פורמטים חדשים אנחנו מזהים, בודקים ומשיקים בעצמנו |
| שליטה | פועלים במסגרת התקן | שליטה מלאה בתרחיש ובנתוני הסשן |
| סיכונים | חלק מהסיכון עובר לתקן | שימוש חוזר בבקשה, סשן ללא הגבלת זמן, החלפת כתובת — בצד שלנו |
החלק היקר ביותר באימות בכתיבה עצמית הוא לא בדיקת החתימה, אלא הסביבה שלה: מזהה בקשה חד-פעמי, קישור לדומיין, תוקף מוגבל לסשן וביטול גישה. סעיף שהוחמץ הופך למחלקת פגיעויות שמשחזרת בלי לפרוץ מפתחות — מספיק לנגן מחדש תשובה שמורה.
לכן כברירת מחדל אנחנו הולכים דרך TON Connect, ובדיקת חתימה עצמאית נלקחת רק במקומות שבהם נדרש תרחיש מחוץ לתקן. במקרה כזה בידוד לוגיקת הבדיקה ומעגל נפרד של בדיקות לחזרה ולהחלפה הם חלק חובה מהעבודה, לא אופציה.
שאלות שנשאלות לפני תחילת אינטגרציה של ארנק
לפני תחילת האינטגרציה של TON Connect מצטברים בצוות ספקות טכניים, וכמעט כולם — לגבי התנהגות המשתמש בגבול התרחיש. להלן תשובות לאלה שצפים בכל דיון: ארנקים, חתימה, סשן ודרך כניסה שנייה.
מה עושים עם ארנקים שאינם נתמכים?
את רשימת הארנקים הנתמכים מקבעים כבר בהתחלה ובודקים אותם בחיבור. במסך הכניסה מציגים רק את אלה שעברו בדיקה, ולשאר נותנים טקסט ברור במקום כפתור תקוע — הסירוב נראה צפוי, ולא כמו «לחצתי ולא קרה כלום».
איך נסגר שימוש חוזר בחתימה?
החתימה מקושרת לערך חד-פעמי ותוקף קצר, והשרת בודק את שני התנאים לפני הנפקת סשן. בקשה שנשלחה שוב נדחית — הודעה שיורטה לא תהפוך לכניסה שנייה.
כמה זמן חי הסשן ומה קורה בעת ניתוק קשר?
הסשן מתארך לפי פעילות ונסגר לפי חוסר פעילות. בעת ניתוק המשתמש חוזר לאותו הקשר, ולא מתחיל את הכניסה מחדש — זה חשוב לטפסים ארוכים ולאישור העברות.
אפשר להוסיף דרך כניסה שנייה?
כן: כניסה דרך ארנק היא לא הנתיב היחיד; לצידה שמים דרך מוכרת (דואר או טלפון), ושתיהן מובילות לאותו פרופיל. את עדיפות הדרכים מקבעים בשלב התכנון, כדי לא לכתוב מחדש את המסך אחר כך.
נדון במשימה: ננתח תרחישים ונחזור עם תוכנית
כדי לחזור עם הערכת אינטגרציה, ולא עם נוסחים כלליים, אנחנו צריכים נתוני קלט על המוצר שלכם. אפילו תשובות ראשוניות מקצרות את זמן הכנת תוכנית העבודה ומסירות אי-ודאות בתחילת הפרויקט. ייתכן שמשהו חסר — חלק נבהיר יחד.
- תרחישי כניסה: אילו תפקידים יש במוצר ומה כל אחד צריך לעשות — רק לבצע אימות, לאשר בעלות על ארנק, לחתום על פעולה או לקשר כתובת לחשבון קיים.
- סכימת הכניסה הנוכחית: מה עובד עכשיו — דואר, ספק חיצוני, סשן עצמאי — ואיך כניסה דרך TON Connect צריכה להתקיים לצידה.
- סביבות: איפה התפקוד יתארח — סביבת בדיקות, קדם-ייצור, דומיין ראשי — והאם נדרשות כתובות נפרדות לבניות מובייל.
- ארנקים: עם אילו אפליקציות משתמשים מגיעים בתדירות גבוהה יותר, ואילו דורשות בדיקה נפרדת של ההתנהגות בחיבור ובסירוב לחתום.
- מגבלות: דרישות לאחסון סשנים, תוקף אסימונים, כללי גישה בתוך הצוות, תנאים רגולטוריים חיצוניים.
- מדדים צפויים: איזה שיעור משתמשים צריך להעביר לכניסה החדשה, זמן החיבור הרצוי, ולפי אילו מדדים תבדקו את התוצאה אחרי ההשקה.
- חומרים: גישה למאגר הקוד, סכימת האימות הנוכחית, תיאור ההחלפה עם הבקאנד, חשבונות בדיקה, דוגמאות לוגים של פניות.
תארו את המשימה בצורה חופשית וצרפו את מה שיש. אנחנו ננתח את התרחישים, נפרט בנפרד את הסיכונים בגישה לארנקים, ונחזור עם הערכת אינטגרציה ותוכנית עבודה לפי שלבים — עם נקודות שבהן תוכלו לבדוק תוצאה ביניים.