WEBA

טוקנים באורך 520 תווים של GitHub שוברים אינטגרציות ישנות

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

549 מילים17 עובדות אומתו

הנחות יסוד ישנות בקוד נוטות להתפוצץ ברגע הכי פחות נוח. שנים התרגלתם שטוקן של GitHub הוא מחרוזת קבועה של 40 תווים שנכנסת לכל עמודה צרה בבסיס הנתונים. אתמול, לפי הודעת העדכון של החברה, הושלמה רשמית הפריסה ההדרגתית של טוקני התקנה חסרי-מצב (stateless) עבור GitHub Apps. אם המערכות שלכם לא נבדקו מאז תחילת המהלך ב-27 באפריל 2026, צפו לבעיות באימות.

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

מ-40 תווים ליותר מ-500

ברירת המחדל החדשה של כל טוקן התקנה שנוצר עבור יישומי GitHub עברה לפורמט ghs_APPID_JWT. השינוי המרכזי שרואים מיד בעיניים הוא האורך. במקום 40 תווים בלבד, הטוקנים החדשים מגיעים כעת לאורך של כ-520 תווים באורך משתנה. לפי החברה, המטרה מאחורי המהלך הזה היא שיפור ביצועים ויציבות של ממשקי ה-API. טוקנים מבוססי JWT כוללים את כל נתוני ההקשר בתוך המחרוזת החתומה עצמה. זה מאפשר הנפקה ואימות מהירים יותר בצד השרת, בלי לפנות בכל פעם מחדש למסד נתונים מרכזי כדי לבדוק האם הטוקן תקף.

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

The staged rollout of the stateless GitHub App installation token format, which began on April 27, 2026, is complete. By default, all newly minted GitHub App installation tokens will be in the stateless ghs_APPID_JWT format, which makes token issuance and validation faster and improves the reliability of the GitHub API.GitHub Changelog

מה נשאר בדיוק אותו דבר

לפני שמתחילים לשכתב לוגיקה עסקית, כדאי להבין מה לא זז. הקידומת המוכרת ghs_ נשארה במקומה בתחילת המחרוזת, וכך גם נקודת הקצה בתוך REST API שמשמשת ליצירת הטוקנים, כפי שמפורט במדריך של Generating an installation access token for a GitHub App. מודל ההרשאות, תחימת הגישה למאגרים ספציפיים ותוקף הטוקן, שעומד על שעה אחת בדיוק, לא שונו כלל. טוקנים שהונפקו לפני השלמת המהלך ימשיכו לתפקד כרגיל עד שיפוג תוקפם הטבעי.

השינוי הזה נוגע רק לטוקנים שמונפקים עבור התקנות של יישומי GitHub App. הוא אינו רלוונטי למי שמשתמש בטוקני גישה אישיים (Personal Access Tokens) או ביישומי OAuth ישנים. לא הייתי ממהר להאשים את GitHub במהלך כזה, כי המעבר ל-JWT הוא צעד טכנולוגי נכון שפותר צווארי בקבוק היסטוריים, אבל חוסר האחידות הזמני מול מערכות שונות דורש ערנות כפולה.

טוקנים קיימים לא יימחקו פתאום, ואין צורך לבצע ביטול יזום ומאולץ.

ארבע נקודות כשל בקוד

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

נקודת הכשל השלישית נמצאת בתשתיות הרשת. שרתי פרוקסי, שער רשת ארגוני (API Gateway) או רכיבי תווך עלולים להגביל את גודל הכותרות הנכנסות, ולחתוך או לדחות כותרת Authorization ארוכה במיוחד. הנקודה הרביעית נוגעת לכללי סריקת סודות בצינורות CI/CD ובבדיקות אבטחה של GitHub Actions. מפתחים ומהנדסי DevSecOps בישראל, שמפעילים כלי סריקה פנימיים או מוצרים לבדיקת קוד ומאגרים, נדרשים לוודא שמנועי זיהוי הדליפות מזהים את הפורמט החדש ולא מתעלמים ממנו בטעות.

בדיקה קצרה היום תחסוך לכם לילה לבן של שחזור תקלות מחר.

דדליין בנובמבר והסרת כותרות

כדי לאפשר בדיקות יזומות במהלך שלבי הפריסה המדורגת, GitHub סיפקה כותרת בקשה מיוחדת בשם X-GitHub-Stateless-S2S-Token. לפי הודעת החברה, הכותרת הזו תבוטל סופית ב-30 בנובמבר 2026. החל מתאריך זה, GitHub תתעלם לחלוטין מנוכחות הכותרת הזו, וכל האפליקציות המתאימות יקבלו אך ורק את הפורמט החדש. אם הטמעתם את הכותרת הזו בקוד הייצור שלכם כדי לבצע בדיקות מבוקרות, נקו אותה מהמערכות לפני סוף החודש הבא.

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

השאר יגלו את זה כשהקריאות הראשונות ייכשלו.

מה לעשות עכשיובדקו עכשיו שאינכם מגבילים את אורך הטוקן ל-40 תווים במסדי נתונים ובקוד, והסירו את כותרת הבדיקות עד 30 בנובמבר 2026.

מקורות

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

מה שואלים על זה

האם צריך להנפיק מחדש את כל הטוקנים של ה-App באופן יזום?

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

מה קורה אם מסד הנתונים שלי מוגדר לעמודת VARCHAR(40)?

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

מה תפקיד הכותרת X-GitHub-Stateless-S2S-Token ומתי היא מפסיקה לעבוד?

הכותרת שימשה לבדיקה ידנית של הפורמט החדש לפי דרישה. היא תוצא משימוש ב-30 בנובמבר 2026, ויש להסירה מקוד הייצור.

האם מבנה ההרשאות או תוקף הטוקן השתנו בעקבות המעבר ל-JWT?

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