אימות דרך Phantom ב-Solana: היכן הכניסה נשברת
אימות דרך Phantom ב-Solana נראה כמו שלושה שלבים: הארנק חותם על מחרוזת, השרת בודק את החתימה, המשתמש מגיע לאזור האישי. בפועל, כניסה דרך ארנק קריפטו נשברת לפחות בארבעה מקומות, וכל אחד מהם נותן סוג אחר של כשל — משקט של "לא מכניס" ועד פרופיל זר על המסך.
הראשון — אמון בנתונים שמגיעים מצד המשתמש. אם חתימת האישור נבדקת בצד הלקוח, והשרת מקבל החלטה מוכנה, בקשה כזאת נבנית ידנית בקונסול הדפדפן. הבדיקה חייבת להתבצע בשרת, להסתמך על המפתח הציבורי ועל בקשה חד-פעמית שאותו שרת הנפיק וזכר.
השני — תוקף הבקשה החתומה. תוקף ארוך הופך את החתימה לכרטיס מעבר לשימוש חוזר, תוקף קצר יוצר מרוץ: המשתמש מאשר כניסה, והבקשה כבר פגה. מכאן אובדן סשן בדיוק ברגע הכניסה ולחיצות חוזרות על "חבר ארנק" בלי תוצאה.
השלישי — אי-התאמת רשת וחוסר סנכרון במצב הארנק. כתובת שנחתמה בסביבת בדיקות לא צריכה להתקבל בסביבת ייצור; החלפת חשבון בלי קישור מחדש חושפת פרופיל זר. ננתח איך לסגור כל נקודה — כדי שתקלות כניסה לאזור האישי יפסיקו להיות נורמה, והסשן ישרוד רענון עמוד והחלפת מכשיר.
מה משתנה לאחר ההטמעה: מהירות כניסה וביטול סיסמאות
כניסה עם סיסמה היא שרשרת: הזנת כתובת דוא"ל, המתנה למכתב עם קוד, הזנת סיסמה, גורם שני, חזרה על פעולה במקרה של שגיאת הקלדה. לאחר חיבור אימות דרך Phantom נשארת פעולה אחת — אישור בארנק. חמישה שלבים מתקפלים לאחד, והאדם מגיע לאזור האישי בשניות, ולא בדקות של המתנה למכתב.
עמידות הכניסה עולה לא מ"נוחות", אלא מפני שנעלמים מחלקות שלמות של כשלים. אין סיסמה — אין מה לשכוח ואין מה לאפס; אין מכתב עם קוד — אין תלות במסירת דואר ובמסנני ספאם. שיעור ניסיונות הכניסה הכושלים יורד פי כמה: נשארים רק סירוב המשתמש בארנק ואובדן גישה לארנק עצמו.
עבור השירות זה מסיר עומס מתמיכה: פניות "לא מגיע מכתב", "איפסתי סיסמה אבל לא מכניס", "הזנתי דוא"ל עם שגיאת הקלדה" יוצאות מהזרימה — נשארים מקרים נדירים של שחזור גישה לארנק.
בד בבד מצטמצם משטח הסיכון: השירות לא שומר ולא בודק סיסמאות, די לו לוודא שהחתימה תואמת לכתובת המוצהרת.
אנחנו משאירים כניסה בדוא"ל כדרך גיבוי ומפעילים את החדשה בהדרגה, כדי ששיעור הכניסות המוצלחות לא יירד באף שלב. להלן — מה בדיוק אנחנו עושים ובאיזה סדר.
דרכים לחיבור ארנק: השוואת אפשרויות
חיבור ארנק ואימות הם לא אותו דבר. כתובת ציבורית שהארנק מוסר לא מוכיחה דבר: אפשר להזין אותה ידנית ולראות יתרה של אחר. בעלות על המפתח מאשרת רק חתימה, ומה שהשרת יוכל לבדוק תלוי במצב הנבחר.
גורם בחירה שני — הסביבה שבה המוצר פתוח. בדפדפן שולחני החיבור עם Phantom נוצר דרך תוסף ומחזיק עד ביטול ההרשאה, ובמובייל לדפדפן נייד אין תוסף — הכניסה מבוססת על חזרה מאפליקציית הארנק. להלן האפשרויות שביניהן באמת בוחרים.
| דרך כניסה | מתי מתאים | מגבלות השיטה |
|---|---|---|
| תוסף בדפדפן | ווב שולחני, המשתמש מתקין תוסף | לא זמין במובייל; הסשן נשבר בעת ביטול ההרשאה |
| חזרה מאפליקציית הארנק באמצעות קישור | ווב נייד ללא תוסף | נדרש מטפל חזרה ושחזור הקשר העמוד |
| סט מתאמים למספר ארנקים | אי אפשר לדרוש ארנק אחד ספציפי | יקר יותר בתמיכה: למתאמים סט שונה של שיטות חתימה |
| חתימת הודעה עם קוד חד-פעמי | אימות מלא עם קישור לחשבון | צריך לאחסן ולבטל קודים, אחרת החתימה ניתנת לשחזור |
| כתובת ציבורית בלבד ללא חתימה | חלונות ראווה, צפייה ביתרה, אנליטיקה | לא מאשר בעלות על המפתח — לא מתאים כאימות |
הפרדת מצבים חשובה גם לנסיגות: ביטול הרשאה בתוסף קורע את הסשן, ואת הקוד שהשרת כבר הנפיק אסור להשתמש שוב אם הוא מבוטל לאחר הבדיקה. לכן את תוקף הקוד ואת כלל ההנפקה החוזרת אנחנו מקבעים בקונפיגורציה, ולא משאירים לשיקול דעת הלקוח.
שלבי הטמעה: מניתוח המשימה עד מסירה
סדר העבודות כמעט לא תלוי במה שנותנת הכניסה דרך Phantom — אזור תשלומים, גישה לטוקנים או מדור סגור. משתנים נתוני הקלט והדרך שבה הארנק מקושר לחשבון. להלן — רצף השלבים והתוצר בסופו של כל שלב.
- ניתוח תרחישי כניסה. אילו תפקידים נכנסים, מאילו מכשירים — תוסף בדפדפן, ארנק נייד, כניסה עם קוד — ומה רואה משתמש בלי ארנק. בפלט: רשימת תרחישים מוסכמת עם עדיפויות.
- סכמת אימות. איך נוצרת הודעה חד-פעמית, היכן נשמרת, כמה זמן חיה, מה נחשב כניסה מוצלחת. מקבלים סכמה עם נקודות כשל והחלטה כיצד הארנק מקושר לחשבון.
- הגדרת בדיקת חתימה. בדיקת שרת לחתימה ולמפתח ציבורי, הגנה מפני שימוש חוזר בהודעה, קישור וניתוק קישור של ארנק. כאן לרוב צפות שגיאות שאחר כך יקר לתקן.
- הטמעה במערכת. סשנים, תפקידים והרשאות, הנפקה ורענון של טוקני גישה, מספר ארנקים לחשבון אחד, יומן כניסות.
- בדיקות. תרחישים שליליים: החלפת חתימה, שימוש חוזר בהודעה חד-פעמית, תוקף שפג, גישה שבוטלה. מתעדים התנהגות צפויה בכל כשל ומדדים של כניסות מוצלחות.
- מסירת הפרויקט. מאגר וקונפיגורציה, תיאור הסכמה, תיעוד לחיבור ארנק או רשת חדשים, הנחיות לתמיכה. מקיימים סקירה עם הצוות שלכם.
עד למועד המסירה יש לכם כניסה עובדת, מכוסה בבדיקות, ותיעוד שהצוות יכול לפתח לפיו בלעדינו. תארו את המשימה — נחזור עם הערכה ותוכנית לפי השלבים האלה.
הרכב האספקה: סכמות, מדיניות גישה, נהלים
לאחר המסירה ללקוח נשארת לא רק כניסה עובדת דרך ארנק, אלא גם סט מלא של תוצרים שאפשר לפתח ולתחזק לפיהם את המערכת בלעדינו. להלן — מה שנכלל באספקה כברירת מחדל; הסט מכסה את הדרך מהכניסה הראשונה של המשתמש ועד לפעולות צוות התורנות בעת תקלה.
- סכמת זרימות נתונים — איך בקשת חתימה יוצאת אל Phantom, מה חוזר לבקאנד, היכן נבדקת האותנטיות ואיך מונפק סשן; בנפרד מסומנות נקודות שבהן הנתונים לא צריכים לצאת מהמתאר.
- מדיניות גישה — תפקידים, תוקף סשן, כללים לקישור ארנק לחשבון וביטול גישה בעת חשיפת מפתח.
- סכמת רוטציה של סודות ומפתחות — מי, באיזה סדר ולפי איזה סימן מחליף ערכים, כך שההחלפה לא מפילה סשנים פעילים.
- נהל תמיכה — פניות טיפוסיות (חתימה לא עוברת, כתובת לא תואמת, הסשן פג), שלבי אבחון וגבולות שבהם אנחנו מצטרפים.
- הנחיות לצוות התורנות — היכן לבדוק יומנים, אילו סימנים מצביעים על ניסיון להחליף חתימה, מה לעשות בדקות הראשונות.
- קונפיגורציית סביבות — סביבת בדיקות וסביבת ייצור מופרדות, הערכים מועברים למשתנים, סודות לא נמצאים במאגר.
- רשימת בדיקה לקבלה — תרחישי כניסה, שימוש חוזר בחתימה, פקיעת סשן וכשל, עם התנהגות מערכת צפויה לכל אחד.
הסכמות והמדיניות מעוצבות כך שמהנדס חדש בצוות יבין מהן בלי התכתבות עם המחברים. את נהל התמיכה נתאם עם תהליך התורנויות שלכם — תארו את המשימה, ונחזור עם הערכה ותוכנית.
מקרה בוחן: איך החזרנו את הכניסה לאזור האישי והסרנו תקלות
מה היה לפני העבודות
הלקוח הגיע עם אימות עובד אך לא יציב דרך Phantom: חתימת ההודעה נבדקה בצד הלקוח, ולשרת נשלח סימן מוכן "חתם". כל חוסר סנכרון בארנק — החלפת חשבון, מעבר רשת, חתימה חוזרת — השאיר במאגר סשן תלוי.
משתמשים עם שני ארנקים נכנסו בניסיון השני-שלישי, והתמיכה טיפלה בעשרות פניות בשבוע על "לא מכניס לאזור האישי".
שיעור הכניסות המוצלחות בניסיון הראשון עמד על כ-68%, וכל תקלה נסגרה ידנית: מהנדס מצא את הרשומה, סיים את הסשן וביקש להיכנס מחדש. שחזור גישה ארך מחצי שעה — בעוד שהאזור האישי היה נקודת הכניסה למוצר בתשלום.
מה עשינו ומה השתנה
את בדיקת החתימה העברנו לשרת, בקשת חתימה חד-פעמית קישרנו לדומיין, לרשת ולתוקף של כמה דקות — שימוש חוזר הפך לבלתי אפשרי. החלפת חשבון ורשת בארנק החלה להיות מטופלת במפורש: הסשן הישן מבוטל לפני יצירת חדש, ולכן מצבים תלויים כבר לא נשארים.
לאחר המסירה שיעור הכניסות בניסיון הראשון עלה מ-68% ל-97%, פניות לתמיכה בנושא כניסה ירדו פי שישה, ושחזור גישה הצטמצם לשניות — את הסשן מסיימים כעת בלחיצת כפתור רגילה, בלי מעורבות מהנדס. בשלב נפרד הוספנו יומן אירועי כניסה: בכל כשל רואים באיזה שלב הוא התרחש.
במה כניסה דרך Phantom שונה מכניסה עם דוא"ל וסיסמה?
בכניסה דרך Phantom אין סיסמה בכלל. השרת מוסר הודעה חד-פעמית עם ערך אקראי ותוקף קצר, הארנק חותם עליה במפתח פרטי, והשרת בודק את החתימה לפי הכתובת הציבורית ורק אחר כך מנפיק סשן. אי אפשר להשתמש שוב בחתימה שיורטה: הערך תקף פעם אחת ולזמן מוגבל.
המפתחות נשארים אצל המשתמש — המפתח הפרטי והמשפט המנמוני לא עוזבים את המכשיר שלו ולא מגיעים אלינו. זה משנה את מודל הסיכון.
בכניסה עם דוא"ל וסיסמה אנחנו שומרים האש של סיסמה, חייבים להגן עליו, להגביל ניסיונות ניחוש ולשלוח מכתבים לאיפוס; בסכמה עם ארנק אין מה לשמור, והדלפה של בסיס הנתונים שלנו לא פותחת גישה לחשבונות.
שחזור גישה עובר גם הוא למשתמש. אנחנו לא יכולים לאפס אותו מצדנו: אין לנו סיסמה וגם לא זכות לחתום על פעולה בשם הלקוח — השחזור מתבצע דרך המשפט המנמוני בארנק עצמו. לכן בפרויקט מופיע קישור של כמה כתובות לחשבון אחד ודרך כניסה חלופית כגורם שני — למקרה של אובדן מכשיר.
בתמיכה משתנה סט הפניות: נעלמים "לא הגיע מכתב" ו"שכחתי סיסמה", מגיעים "התקנתי מחדש את האפליקציה", "חותם ממכשיר אחר", "איבדתי גישה לארנק".
תרחישים כאלה אנחנו מכסים מראש ברמזים בממשק — המשתמש צריך להבין מה בדיוק הוא חותם ואיזו כתובת נחשבת ראשית.
ספקות טכניים: אבטחה, סשנים, תמיכה
אימות נבנה על חתימה של הודעה חד-פעמית: ארנק Phantom ברשת Solana חותם על מחרוזת עם ערך ייחודי וחתימת זמן, השרת בודק את החתימה ומנפיק טוקן סשן. המפתח הפרטי לא עוזב את מכשיר המשתמש ולא מגיע ליומנים או לבסיס הנתונים — אין מה לגנוב מצד השירות. אי אפשר להשתמש שוב בחתימה שיורטה: הערך חי זמן מוגבל ומתקבל פעם אחת.
תוקף טוקן הגישה אנחנו מחזיקים קצר, ושל טוקן הרענון — ארוך יותר באופן ניכר: הראשון מגביל את חלון החשיפה, השני מונע צורך בחתימה על כל פעולה. ביציאה או בהחלפת ארנק הרענון מבוטל בשרת, ולכן טוקן גנוב מפסיק לעבוד מיד, ולא ממשיך עד סוף תוקפו.
מיגרציה של משתמשים קיימים מתבצעת בלי לאבד התקדמות: בכניסה הראשונה החשבון מקושר לרשומה קיימת לפי סימן מאושר, ההיסטוריה והתפקידים מועברים כמו שהם. אפשר לקשר פרופיל אחד לכמה ארנקים — כתובת נוספת מאושרת בחתימה נפרדת, והבעלים נכנס מכל אחד מהם.
מה יקרה אם המשתמש יאבד גישה לארנק?
ארנק שני שקושר מראש או ערוץ גיבוי מאושר מחזירים גישה לאותו פרופיל — ההתקדמות והתפקידים נשמרים.
איך השרת מבין שהחתימה ניתנה על ידי הבעלים ולא על ידי אתר זר?
בהודעה אנחנו כוללים את כתובת הארנק, חתימת זמן ואת הדומיין של השירות, והבדיקה נעשית בשרת. חתימה שהתקבלה עבור אתר אחר או בקשה אחרת לא מתקבלת.
נדון במשימה: מה צריך כדי להתחיל עבודה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם ניסוחים כלליים, אנחנו צריכים נתוני פתיחה על המוצר ותרחישי הכניסה. בדרך כלל זו שיחה של 20–30 דקות עם המוצר שלכם, ואם יש אפשרות, גם עם מהנדס שאחראי על הצד השרת.
- תרחיש כניסה: רק Phantom או כמה ארנקים ברשת; האם נדרשת כניסה באמצעות אימייל או טלפון כחלופה שוות ערך.
- מה נחשב חשבון: קישור ארנק לפרופיל קיים, חשבון נפרד או כמה ארנקים למשתמש אחד.
- תפקידים והרשאות: מה זמין לפני כניסה, מה נפתח לאחר אישור בעלות על הארנק ומה דורש אישור חוזר.
- סשנים: תוקף, האם נדרשת יציאה אוטומטית, התנהגות בעת החלפת ארנק או התקנה מחדש של התוסף.
- תשתית: היכן ממוקם הצד השרת, אילו בסיסי נתונים ומאגרים כבר קיימים, האם יש דרישות לאחסון ולשמירת נתונים.
- אבטחה ודרישות רגולטוריות: הגנה מפני שימוש חוזר בחתימה, מה נכנס ליומנים, האם נדרשת בדיקה של פעילות חשודה.
- ממשק: פריסות מסכים, טקסט ההודעה לחתימה, מקום כפתור הכניסה בממשק הנוכחי.
- קבלה: תאריך התחלה רצוי לפרויקט, קיום סביבת בדיקות, מי מצדכם מקבל את התוצאה.
זה מספיק כדי שנחזור עם הערכה ותוכנית עבודה: שלבים, תלויות, אזור אחריות של הצוות שלנו ומה שיידרש מצדכם. תארו את המשימה — נחזור עם הערכה ותוכנית.