שגיאת 401 או 403 במורנינג (Green Invoice): מה ההבדל ואיך מתקנים

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

מה ההבדל בפועל בין 401 ל-403?

| | 401 Unauthorized | 403 Forbidden | |---|---|---| | המשמעות | לא זוהית | זוהית, ואין לך הרשאה | | הסיבה הנפוצה | טוקן פג או חסר | המפתח לא מורשה לפעולה או למסמך | | מה לבדוק ראשון | מתי הופק הטוקן | מה מוגדר למפתח באזור האישי | | האם חידוש טוקן יעזור | כן | לא | | אם זה קורה בדיוק כל שעה | כן, זו החתימה הקלאסית | לא |

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

למה הטוקן פג אחרי שעה

מורנינג לא עובדת עם מפתח API שנשלח בכל בקשה. מפיקים באזור האישי מזהה מפתח וסוד, שולחים אותם ל-`/account/token`, ומקבלים בחזרה JWT. ה-JWT הזה הוא מה שנשלח בבקשות, והוא קצר-מועד.

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

איך בונים חידוש טוקן שלא נופל

1. שמרו את הטוקן יחד עם זמן התפוגה שלו, לא רק את המחרוזת.
2. לפני כל קריאה בדקו אם נותרו פחות מכמה דקות לתפוגה, ואם כן - חדשו מראש.
3. הוסיפו טיפול ב-401 שמחדש טוקן ומנסה שוב פעם אחת בלבד. ניסיון חוזר בלולאה על 401 אמיתי הוא איך שחוסמים חשבון.
4. אל תחדשו טוקן בכל קריאה. זו קריאה מיותרת לכל פעולה והיא תיראה כמו התנהגות חריגה.
5. רשמו בלוג את קוד הסטטוס, גוף התשובה וזמן הפקת הטוקן. זה מה שמאפשר לאבחן בדיעבד.

מה לבדוק כשזה 403 ולא 401

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

מה משתבש בפועל

• טוקן בקוד או בקובץ קונפיגורציה. נכתב פעם אחת, עבד שעה, ומאז נופל.
• בליעת השגיאה. קוד שתופס חריגה ולא רושם את הגוף - ואז אי אפשר לדעת אם זה 401 או 403.
• סביבת בדיקות מול ייצור. מפתח שהופק בסביבה אחת לא יעבוד בשנייה.
• שעון שרת לא מסונכרן. אם השעון סוטה, חישוב התפוגה שגוי והטוקן "פג" מוקדם מהצפוי.
• ריצה מקבילית. כמה תהליכים שמחדשים טוקן במקביל דורסים זה את זה.

איך מאבחנים את זה בשלוש דקות

1. הוציאו מהלוג את קוד הסטטוס וגוף התשובה של הקריאה שנכשלה. בלי הגוף אין אבחון.
2. הפיקו טוקן חדש ידנית מול `/account/token` והריצו קריאת קריאה פשוטה.
3. עבד? זו הייתה תפוגת טוקן. תקנו את מנגנון החידוש, לא את הקריאה.
4. לא עבד באותה שגיאה? זו הרשאה. בדקו את הגדרות המפתח, לא את הקוד.
5. עבד לקריאה אבל נכשל בכתיבה? המפתח מוגבל להרשאות קריאה בלבד.

מה קורה כשכמה תהליכים רצים במקביל

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

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

קשור: אוטומציה מול מורנינג / Green Invoice, השוואת תוכנות חשבוניות ישראליות, מה זה REST API.

מקורות

• morning by Green Invoice API - תיעוד רשמי