מה הכריזה Cloudflare
Cloudflare הכריזה על שדות הזמן האופציונליים not_before ו־expires_on לאסימוני האימות של משתתפים בפגישות RealtimeKit, לצד ביטול אסימון בודד. ברירת המחדל נשארת 100 ימים. אלו בקרות גישה שהוכרזו כעת, לפי יומן השינויים מ־12 בנובמבר.
שלוש החלטות שונות לאורך חיי הגישה
תיעוד המשתתפים מגדיר חותמות זמן בפורמט RFC 3339, תוקף מרבי של 100 ימים ואסימונים המשויכים למשתתף ולפגישה. רענון יוצר אסימון חדש בלי לפסול את הקודם. ביטול אסימון בודד משאיר אסימונים אחרים תקפים, והפצת הביטול לכל המיקומים עשויה להימשך עד 60 שניות.
פקיעת תוקף אינה מנתקת משתתף שכבר מחובר. התחברות מחדש בודקת את האסימון שוב, ותחזיר HTTP 401 אם פג תוקפו. ביטול מסיר משתתף פעיל. מחיקת המשתתף פוסלת מיד את כל אסימוניו לאותה פגישה ומסירה אותו אם הוא מחובר. ההבחנות מפורטות בשאלות והתשובות של RealtimeKit.
רשימת בדיקות מעשית למפתחים
ההמלצה שלנו היא להגדיר תחילה את חוויית השימוש הרצויה, ורק אז לבחור את משך התוקף. בסדנה מתוזמנת, למשל, צריך להחליט מתי אורח רשאי להצטרף, מה יקרה אחרי נפילת רשת ואיך מארגן מבטל הרשאה. כדאי להפוך כל החלטה כזאת לבדיקת קבלה נפרדת, עם תוצאה צפויה שאפשר להסביר גם למי שאינו מפתח.
- בדקו את שני גבולות הזמן. בפגישת ניסוי, נסו להצטרף מעט לפני כל גבול שהוגדר ומעט אחריו. תעדו את זמן השרת ואת התוצאה הצפויה. הוסיפו מכשירים עם שעון שגוי במכוון, כדי לוודא שהתצוגה המקומית אינה הופכת למקור הסמכות להרשאות.
- דמו הפרעה לחיבור. השאירו חיבור פעיל מעבר למועד התפוגה, ואז התחברו מחדש. בדקו שהממשק מסביר לאורח מה לעשות בהמשך, במקום להשאיר אותו בלולאה של ניסיונות חוזרים. ודאו שגם צוות התמיכה יכול לזהות את המצב מתוך הודעת השגיאה.
- עקבו אחר אסימונים חופפים. צרו אסימון חלופי ובדקו בנפרד את האסימון הקודם. החליטו כיצד השרת שלכם מתעד אסימונים שהונפקו ואיזו פעולה מתאימה לבקשת המארגן לבטל גישה. אל תסתפקו בכך שהכפתור מציג הודעת הצלחה.
- מדדו את תהליך ההסרה. צפו באורח מחובר בזמן הפעלת מסלולי ביטול האסימון ומחיקת המשתתף המתועדים. מדדו את ההמתנה ובדקו מה רואה המארגן עד לסיום. כדאי לוודא שהממשק אינו מציג פעולה ממתינה כאילו כבר הושלמה.
- שמרו ראיות בלי לחשוף סודות. תעדו שמות פעולות, זמנים ותוצאות, ולא אסימוני גישה מלאים. השתמשו בפגישות חד־פעמיות ובזהויות בדיקה כלליות. תעדו גם את הדרך שבה משתתף יקבל שוב גישה לאחר הסרה שבוצעה כדין, אם המארגן יחליט להזמינו מחדש.
זו תוכנית בדיקה מוצעת, ולא דיווח על ניסוי בשירות החי. שאלת התכנון החשובה היא איזה אירוע מייצגת כל בקרת גישה באפליקציה שלכם, והאם האורח והמארגן מבינים את המצב שנוצר בעקבותיה.