פיתוח מערכת גישה מבוססת טוקן: מ-SIWE ועד ריבוי רשתות

Token-gated access: היכן נשברת בדיקת הרשאות הגישה

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

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

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

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

מה נותנת גישה מנוהלת: מהירות, כשלים, ביקורת

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

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

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

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

אפשרויות לבדיקת בעלות על טוקן: השוואת מצבים

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

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

הטמעת token-gated access: שלבי העבודה ההנדסית

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

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

מדיניות גישה, סכמות תפקידים ותיעוד

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

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

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

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

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

מה שינינו

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

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

מדדים לפני ואחרי

פתיחת המקטע: היה עד 6 שעות בימי עבודה, הפך ל-30–40 שניות לאחר אישור הטרנזקציה. שיעור המצבים השנויים במחלוקת ירד מכ-7% לפחות מ-1%, וכמעט כל הנותרים — מפתחות שאבדו, ולא חוסר סנכרון בהרשאות. ההצלבה הידנית של הרשימות נעלמה כליל.

במה נבדלת חתימת ארנק מהרשאה רגילה?

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

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

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

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

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

ספקות לגבי בדיקת ההרשאות: סשנים, מטמון ושלילת גישה

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

הבעלים מכר את הטוקן — הגישה תישאר?

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

איך לשלול גישה ממשתתף אחד?

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

מה עם התיישנות המטמון וכניסה משולבת?

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

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

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

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

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