Improper Error Handling
northwind ואת שם הטבלה. מחיקת מוצר שיש לו קשרים בטבלאות אחרות מחזירה הודעת foreign key constraint שחושפת עוד שמות של טבלאות ועמודות. הודעות כאלה לא אמורות להגיע ללקוח, כי האקר מנצל אותן כדי להכיר את המבנה.app.js טוענים את אחד מהם ומעבירים להערה את השני. בהעלאה לאוויר מחליפים ביניהם.isProduction: ב-development הערך false, וב-production true.errors-handler.js עם פונקציה getError. אם config.isProduction אמת, מחזירה הודעה כללית כמו "some error occurred, please try again later". אחרת מחזירה err.message. חושפים אותה דרך module.exports.err.message קוראים ל-errorHandler.getError(err).פרקי ההרצאה: Improper Error Handling
תמלול ההרצאה: Improper Error Handling
הטקסט המלא של הדקות הראשונות בהרצאה «Improper Error Handling» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
הבעיה הראשונה שאנחנו הולכים לתקוף נקראת בז'רגון המקצועי של security improper error handling. זה בעצם מצב שבו המערכת מדווחת ללקוח באופן לא נכון ולא secured הודעות שגיאה.
אבל כרגע המערכת לא מדווחת שום הודעות שגיאה, לפחות כמו שראינו. אנחנו רוצים לדמות כאילו יש פה איזושהי בעיה בשביל לראות מה זה אומר שהמערכת מדווחת הודעות בצורה לא טובה.
אז בואו רק לצורך הדוגמה נלך ונניח טבלת פורומים, נשנה לה פה את השם מפורום לפורום 2. עכשיו במציאות זה לא המצב אבל אני רק רוצה לדמות כאילו יש פה איזושהי קריסה ולראות מה בעצם המערכת מראה לי ברגע שזה קורה.
אנחנו רואים שפורום שונה לפורום 2. אני נמצא ב-Home, אני הולך לפורום, וכמובן הוא לא יכול לתת לי את השירות, אז הוא נותן לי הודעת שגיאה.
אז זה נראה כאילו, מה הבעיה? הנה, הוא נותן לי הודעת שגיאה. אבל זה לא אוקיי. קודם כל, ההודעה הזאת היא בכלל לא אינטואיטיבית כלפי הלקוח.
הלקוח לא אמור לראות הודעות שגיאה של מערכת. בואו נראה מה כתוב פה. Error no such table. Table northwind. Forum doesn't exist.
עכשיו, זה לא אני כתבתי את ההודעה הזאת, או לא המתכנת כתב אותה, זו הודעה אוטומטית שנשלחת על ידי המערכת. מה האקר יכול לדעת?
קודם כל, שיש לנו דאטאבייס שנקרא Northwind, ב. שיש לנו טבלה שנקראת פורום. כל מיני נתונים שאנחנו ממש לא רוצים להעביר אותם לאף אחד. עכשיו, ברור שההאקר לא ילך לפורום וישנה את השם של הטבלה ואז יראה את ההודעה הזאת, כי אם הוא ניגש לדאטאבייס הוא כבר רואה מה יש שם, אבל זה רק דוגמה
להראות שאם מתרחשת קריסה בדאטאבייס, הדאטאבייס חושף לי נתונים שאסור לי להציג אותם ללקוחות הסופיים. בואו נראה דוגמה נוספת. נניח אני הולך, בואו רק נחזיר את הטבלה הזאת לשם הקודם שלה, בכדי שלא ייצר לנו בעיות בהמשך.
אם אני הולך ומבצע איזושהי פעולה לא חוקית מבחינת הדאטאבייס, נניח אני הולך ל-CHI ומוחק אותו, אני מנסה למחוק אותו, כל ההודעות האלה שאתם רואים כרגע שהמערכת נותנת לנו, מה SQL מראה לנו, אלה הודעות שכאמור by default אנחנו זורקים ללקוח,
אם אנחנו לא מטפלים בזה כמו שצריך. בואו נראה מה ההודעה הזאת אומרת, cannot delete or update a parent or a foreign key constraint fails. הנה הוא חשף לנו את השם של הדאטאבייס, הנה הוא חשף לנו שם של טבלה א', חשף לנו שיש relationship, הנה הוא חשף שם של עמודה.
אוקיי, הנה עוד שם של טבלה, אנחנו רואים שההודעות האלה, הודעות החריגה, אסור להן להגיע ללקוח הסופי. יכול להיות שהאקר יבוא וינסה לבצע כל מיני פעולות אסורות, אולי האתר מאפשר לו למחוק איזה משהו, אז הוא ינסה למחוק משהו אסור, בום, מקבל הודעות קריסה.
אנחנו לא רוצים שההודעות האלה יגיעו ללקוח. אז מה אנחנו עושים? אז קודם כל אנחנו צריכים להבין שאם אנחנו נמצאים בשלב של הפיתוח, מה שנקרא development, אנחנו כן רוצים לראות את ההודעות האלה, יש פה איזושהי קריסה, אני רוצה לטפל בה.
אולי הקריסה הזאת היא באמת קריסה בקוד שלנו בתור מתכנתים, אבל אם אנחנו נמצאים במצב של פרודקשן, זאת אומרת שהאתר הוא באוויר, אנחנו לא רוצים להציג את ההודעות האלה.
למה ההודעות האלה נשלחו? בואו נסתכל על הקונטרולרים שתמיד בנינו. כל הודעה כזאת, בואו נלך לפורום, אנחנו תפסנו את הקריסות בcatch, דיווחנו הודעת 500 שזה בסדר, אבל תמיד תמיד שלחנו err.message וזה הדבר הלא נכון.
אנחנו צריכים לשלוח err.message רק אם אנחנו ב-development, בזמן הפיתוח. אם אנחנו בפרודקשן, המערכת הזאת נמצאת באתר אמיתי באוויר, אנחנו רוצים לשלוח הודעה כללית, שהיוזר יבין שיש איזושהי בעיה כרגע, אבל בלי לחשוף לו שום מידע.
כאשר אנחנו למדנו על קבצי קונפיגואציה ראינו בדיוק ויש איזשהו סוג של פתרון כזה שאומר, יש שני קבצים שאנחנו יכולים להגדיר, אחד עבור Production, אחד עבור Development.
אז בואו ניקח את ה-Config, ונגיד שה-Config הזה הוא עבור Development, ונשכפל אותו, ונגיד שה-Config הבא הוא עבור Production, dev ו-prod.
כרגע אין ביניהם שום הבדל. דבר נוסף, אנחנו צריכים לגשת ל-app, ולשנות את זה. יש לנו פה כרגע config/development, נשכפל ל-prod, אבל נשים את ה-prod בהערה כרגע.
ואז כל מה שאנחנו צריכים לעשות כשאנחנו מעלים את האתר לאוויר זה להחליף בין החבר'ה האלה, ויש לנו בעצם אפשרות להחליט איזה קבצים כרגע פעילים.
אז מה שאנחנו רוצים לעשות זה להגיע לקובץ, בעצם לשני הקבצים, נתחיל עם הדיבלופמנט ובדיבלופמנט אנחנו רוצים להגדיר שיש לנו פה משתנה שנקרא is production.
אנחנו נמצאים בדיבלופמנט אז הרקור הוא false ונשכפל אותו לפרודקשן ובפרודקשן נגיד true. כמובן הם חייבים להיות בצורה כזאת. אז דבר ראשון אנחנו רואים שבדיבלופמנט ובפרודקשן יש איזשהו משתנה שאומר האם אנחנו בשלב של דיבלופמנט או בפרודקשן.
ואנחנו יכולים עכשיו להשתמש במשתנה הזה בכדי לדעת באיזה מוד אנחנו, איך אנחנו משתמשים בזה. בואו ניגש ונבנה תיקייה helpers שתעזור לנו, יש פה כל מיני עזרים שאנחנו הולכים להשתמש בהם.
בתוך helpers נוסיף קובץ, נקרא לו errorsHandler.js ונבנה פה פונקציה,