הסבר על סשן Session לאימות משתמשים
api/products מקבל את כל המוצרים גם בלי לוגין, כי השרת עונה לכל פנייה. כל מה שמגיע לצד הלקוח נגיש לכולם.express-session ומגדירים אותו עם server.use: שם לעוגייה, secret להצפנת ה-session ID, resave ו-saveUninitialized בערך false.request.session.loggedIn = true רגע לפני החזרת התשובה.verify-logged-in.js בודק את ערך הסשן. אם הוא לא קיים (undefined או false) מחזירים סטטוס שגיאה והודעה "you are not logged", ואחרת קוראים ל-next().router.use עם ה-middleware, כך שכל route של המוצרים מוגן. הפורום נשאר פתוח כי כך נקבעה הלוגיקה של האתר.request.session.destroy ואז response.end. בלי זה השרת ממשיך להתייחס למשתמש כמחובר גם אחרי יציאה.out.js בצד הלקוח, לפני הניתוב לדף הבית, שולחים בקשת POST ב-jQuery Ajax ל-/api/auth/logout. בשגיאה מציגים alert, ורק בהצלחה עוברים לדף הבית.next.api/products וגם המשתמש המזויף ב-F12 נחסמים. אחרי login חוקי רואים מוצרים, ואחרי logout שוב נחסמים.פרקי ההרצאה: הסבר על סשן Session לאימות משתמשים
תמלול ההרצאה: הסבר על סשן Session לאימות משתמשים
הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על סשן Session לאימות משתמשים» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אנחנו מגיעים לפרצת האבטחה הבאה בתור. כאן אנחנו נמצאים באתר והיוזר שלנו הוא לא רג'יסטר, בוא נגיד אפילו שאין לו חשבון. והוא הולך להום, הוא יכול לראות את הום, הוא יכול לראות את הפורום, הוא בא להיכנס לפרודקטס, כמובן שמחת אומרת לו, תשמע, בוא תעשה לוגין, אתה לא יכול לראות את המוצרים בלי לעשות לוגין.
ויכול להיות שאותו האקר, בוא נקרא לו ככה, בעצם ראה חבר שלו מתעסק עם האתר הזה אולי איזה קולגה בעבודה וברגע שהקולגה בעבודה לא היה ליד המחשב אז כמובן להאקר יש גישה למחשב שלו והוא יכול לבדוק לאן בדיוק האתר גולש מה הג'אווה סקריפטים שקיימים פה מה כתוב ב-F12 כל מיני נתונים כאלה שהם בין כה נמצאים בצד הקליינט כל מה שמגיע לצד הקליינט נגיש לכל אחד.
אז אותו האקר יכול להגיד, אוקיי, אתה לא נותן לי לראות את המוצרים? אין בעיה, אל תיתן לי לראות את המוצרים. אני גולש לבד ל-api/products.
בום, מה אנחנו נותנים לו? את כל המוצרים. אז אולי אנחנו לא נותנים לו את זה בצורה ממש אסתטית ויפה, אבל הנה הוא קיבל מידע רגיש, מפני שהשרת קיבל פנייה על ידי דפדפן, ידי פוסטמן לא משנה איך לראוט הזה וזה רסטפול סרוויס אז הוא נותן בחזרה את אותה אותה מידע שהוא מספק
אז הנה כבר היוזר מבלי לבצע לוגאין ומבלי להיות לוגאין ראה את המידע שמבחינתנו אנחנו יכולים להציג אותו רק אם עברו לוגאין דבר נוסף שהוא יכול לעשות בואו אפילו נלך שימו לב אני לא יכול לראות את המוצרים בצורה כזאת נלך ל-F12 אפליקיישן אם אותו האקר יודע מה אנחנו שותלים פה אז הוא יכול להגיד טוב אני יוצר לעצמי איזשהו אובייקט יוזר וזה איזשהו אובייקט
ג'ייסון ואני ראיתי באיזשהו מחשב של קולגה ב-F12 שזה first name בואו נקרא לזה ha ב-last name, בואו נקרא לזה גם ha וזה היוזר שאני כרגע שותל בתוך ה-f12.
בואו ניכנס למוצרים ובום אנחנו רואים את המוצרים מפני שה-client side ביצע את הבדיקה ולא ה-server side ושימו לב מה השם של היוזר אז כמובן זאת בדיחה שהצלחנו להיכנס ולראות את המוצרים אפילו שאנחנו לא לוגדין, ובטח שאין לנו יוזר כזה.
מה הבעיה בכל האתר? הקליינט מבצע את הבדיקה, שזה בסדר, אבל לא הסרבר. הסרבר שלנו גם הוא צריך לבצע את הבדיקה הזאת.
בואו נבצע לוג-אאוט, אחר כך ננסה את זה שוב. אנחנו רוצים לעבור לסרבר ולהגן מפני כניסות יוזרים לא מורשים. אז איך אנחנו עושים את זה? יש לנו כמה דברים שאנחנו צריכים לתמוך.
אנחנו יכולים לעשות את זה באחת משתי שיטות. שיטה אחת זה להשתמש במה שלמדנו כבר בעבר, שזה סשן, ואם היוזר מצליח לבצע לוגאין, להגיד לו, תשמע, אתה עכשיו לוגאין, אין לנו בעיה איתך, אתה יכול לקבל את כל מה שלוגאין יכול לראות.
זאתי שיטה אחת, את זה נראה בסרטון הזה. בסרטון הבא נראה שיטה אחרת, שהיא אפילו יותר פופולרית ויותר טובה מהשיטה הזאת, אבל בואו נראה את שתי השיטות.
אנחנו רוצים להגדיר פשן, לכן מה שאנחנו רוצים לעשות זה קודם כל, בואו נעצור, נתקין פשן. אז יש לנו npmi express session go ויש לנו פה התקנה של מה שדרוש עבור תמיכה בפשן בצד של השאר. עבדנו כבר בעבר באחד הסרטונים הקודמים עם פשנים באיזשהו נושא מיוחד לפשן.
מה שאנחנו צריכים לעשות זה לבוא לפה, קודם כל const ובואו ניצור session שווה require וזה יהיה express session. אחרי שיש לנו את האובייקט ה-fashioned אנחנו רוצים, האמת שזה של המערכת אז אני אעלה אותו פה למעלה, אני תמיד מסדר את המערכת קודם ואז את שלנו קודם ואז משתנים של פונקציות כאלה אחר כך.
אנחנו רוצים עכשיו להגדיר, אפילו נעשה את זה פה, server use ולבוא ל-session ולהגיד לו קונפיגורציה בסיסית של fashion שראינו בעבר. והקונפיגורציה אמרה קודם כל מה השם של הקוקי שהולך להישמר עבור ה- fashion הזה, בואו נקרא לזה Northwind fashion, לאחר מכן secret איזושהי מחרובת בשביל להצפין
את אותו fashion ID, נקרא לזה tensRU, ולאחר מכן אנחנו רוצים ריסייב זה יהיה true כמו שעשינו בעבר ולבסוף save uninitialized false שתי הגדרות קונפיגורציה שדיברנו עליהן והנה יש לנו עכשיו תמיכה בפשן האתר תומך כרגע
בפשן הדבר הבא שאנחנו רוצים לעשות זה לגשת לאזור הקונטרולר של הלוגין in authentication יוזר יכול לעשות רג'יסטר ויכול לעשות לוגין גם אם הוא עשה רג'יסטר וגם אם הוא עשה לוגין, מבחינתי היוזר לוגד אין.
אז מיד אחרי שביצענו את כל הפעולות וראינו שהוא עבר בהצלחה ולא קרס או משהו כזה, שנייה לפני שאני מחזיר לו תשובה, אני הולך ל-recurse session ואני מכניס לוגד אין, ממציא משתנה true.
זה אומר מבחינתי שהוא לוגד אין. אנחנו רוצים לבצע את אותו הדבר גם בלוג אין. אם הוא הצליח לבצע לוג-אין בהצלחה אחרי האיף הזה, אותו סיפור request.session.loggedin = true ואז מבחינתי היוזר הוא לוג-דה-אין.
מה עוד אנחנו רוצים? אנחנו עכשיו רוצים להגדיר בעצם middleware. אנחנו צריכים לבנות כאן, קודם כל נבין למה אנחנו צריכים middleware. על מה אנחנו בעצם רוצים להגן?
אנחנו רוצים להגן על פרודקט. פורום, אין בעיה, ראינו. תקבל את כל ההודעות או תוסיף איזו הודעה שאתה רוצה, כל אחד יכול להוסיף הודעה, זו הלוגיקה שלנו. גם פורומים אמיתיים בתעשייה, אתם יכולים להיכנס לפורום ולהודיע הודעות גם בלי להיות רשום בחלק.
כמובן שיש לוגיקות שאומרות, אתם כן צריכים להיות רשומים בשביל פורומים, אבל באתר שלנו לא חייבים, אז אין לי פה הגנה, רק על המוצרים יש לי הגנה.
כל פונקציה כזאת שאנחנו רוצים להגן עליה, השיטה הכי טובה זה בעזרת מידלוויר. אנחנו יכולים להגדיר את המידלוויר כאן, כמו שלמדנו בעבר, שמאפשר לבדוק את אותו מידלוויר רק אם גולשים לראוט הזה, או שאנחנו יכולים להשתמש ב-router.use בשביל לבדוק את כל הפונקציות שנמצאות בקונטרולר שלנו.
אז תכף נחליט באיזה מ"ם אנחנו רוצים להשתמש, הדבר הנכון ופשוט לבנות מידלוויר שבודקת לנו האם היוזר לוגד אין במקום לבדוק את זה שוב ושוב בכל מקום שאנחנו צריכים כי יכול להיות שבהרבה מקומות באתר אני רוצה לבדוק רגע אם אתה לא לוגד אין אני מעיף אותך בחזרה עם שגיאה
לכן בואו נייצר מידלוויר בתוך המידלוויר בואו נכניס verify logged in js יש לנו כאן function verify logged in בואו נברר שאתה לוגד אין בגלל שזה middleware יש לנו request response ו-next וכל מה שאני עושה זה בודק את הסשן אם not request session logged in אוקיי זה בעצם אותו משתנה אפשר לקרוא לו גם is logged in
אבל כרגע קראתי לו logged in, איפה הוא נעלם לי? אם לא קיים לי דבר כזה, או שהוא undefined או שהוא false, לא משנה, לא קיים דבר כזה, אני ניגש ל-response.status ואני שולח סטטוס ויש שני סטטוסים שנהוג לשלוח במצבים של האותנטיקיישן 401 או 403. מה ההבדל?
ארבע מאות ואחת זה unauthorized זה מצב שבו