
LimitFilter שיורשת מ-ActionFilterAttribute. עושים override רק ל-OnActionExecuting, כי הבדיקה נעשית לפני ה-Action. את הקריאה ל-base אפשר להסיר, כי היא לא מועילה כאן.DailyQuota, בדוגמה 1000 פעמים ביום. חריגה נחשבת ניצול לרעה (abuse) של ה-API החינמי.Dictionary שבו המפתח הוא כתובת ה-IP והערך הוא מספר הבקשות (request counts).HttpContext.Connection.RemoteIpAddress. אם כבר קיים מפתח, מגדילים את הערך ב-1, ואחרת מוסיפים את הכתובת עם 1.ContentResult עם StatusCode של Forbidden, תוכן הודעה שחרגת מהמכסה היומית ושמציינת את מספר הבקשות, ו-ContentType של טקסט רגיל. מציבים אותו ב-context.Result, והבקשה חוזרת בלי להגיע ל-Action.Result, והזרימה ממשיכה.GetAllBooks. בקריאה השישית ב-Postman מתקבלת הודעת החריגה.הטקסט המלא של הדקות הראשונות בהרצאה «יצירת Short-Circuit Filter» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אז נשארנו לראות רק את שירט סרקט פילטר. בואו נוסיף עוד פילטר לתיקיית ה-middleware ובואו נבנה פילטר שבעצם בודק כמה פעמים משתמשים גולשים ויש לו איזה קוואטה לימיט מסוים שהוא לא מאשר לגלוש מעבר. נניח שה-Rest API שלנו הוא חינמי ואנחנו אומרים אוקיי תשתמשו בחינם אבל לא מעבר לאיזשהו דיילי מסוים.
טוב, אז בואו נלך ונבנה אותה limit filter, go. ואנחנו רוצים כמובן לבצע פה הורשה של action filter attribute, ומה שאנחנו בעצם רוצים לעשות כרגע זה לדרוס אך ורק את הפונקציה on action executing, כי אנחנו רוצים לבצע משהו לפני, ולכן לא מעניין אותי מהפונקציה שתתבצע אחרי הפילטר, אם הכל בסדר אני מאשר את הזרימה אם משהו לא
בסדר אני מיד מחזיר תשובה מבלי להמשיך לאקשן דרך אגב במקרים האלה לא צריך את ה-base on action executing שהיה גם כאן אפשר להיפטר ממנו וגם היה לנו פה את זה אנחנו לא צריכים אין משמעות לזה כרגע אם תראו שפעם משהו לא עובד אין בעיה להחזיר את זה אבל אני לא רואה סיבה שאנחנו צריכים את זה כרגע זה היה רק בוא תפנה לבסיס שגם הוא יעשה את מה שהוא אמור לעשות אבל הוא לא אמור לעשות
במקרים האלה שום דבר בוא נתחיל עם פרייבט קונסט אינט איזה שהוא דיילי קווטה כזה נגיד אלף פעמים אתה יכול להשתמש ביום אבל לא יותר מזה אחרת אתה עושה לי משהו שנקרא הביוז אתה מנצל לרעה את ה-Rest API החינמי שאני נותן לך לאחר מכן אנחנו רוצים איזה שהוא דיקשנרי דיקשנרי זה קולקשן שיש לו key value ואנחנו רוצים שה-key יהיה סטרינג שזה ה-IP אדרף של היוזר ואנחנו
אנחנו רוצים שה-value יהיה כמה פעמים, הוא גלש לנו באותו זמן או באותו יום, הוא לא משנה, ובואו נקרא לו quotas, נניח, או requests, או לא משנה, בואו נקרא לו request counts, כמה פעמים אתה מבצע גלישות, ואנחנו רוצים לייצר dictionary חדש בצורה כזאת.
אוקיי, יש לנו עכשיו את הפרמטרים. מה אנחנו רוצים לעשות? דבר ראשון, בואו נקבל את ה-IP address של היוזר, סטרינג IP שווה קונטקסט HTTP קונטקסט נקודה קונקשן remote address נמיר אותו לסטרינג ונגיד לו תקשיב זה הולך להיות remote address הכל טוב נקסט הדבר הבא שאנחנו רוצים זה לבדוק האם הIP הזה כבר קיים ב-request counts הזה אם ה-request counts נקודה contain key IP
אז זה אומר שהיוזר כבר גלש לשירות שלנו והוא אמור כבר להופיע שם. אז אנחנו רוצים לפנות אליו request counts במיקום IP, פלוס פלוס, ולהעלות אותו ב-1.
אחרת הוא פעם ראשונה גולש אלינו, request counts נקודה add, בוא תוסיף לי את ה-IP עם המספר 1, כי זו פעם ראשונה שהוא גלש אז זו גלישה ראשונה שלו.
אם זו לא גלישה ראשונה הוא ייכנס לפה ויעלה אותו ל-2, 3, 4, 5, לא משנה, ואנחנו נוכל לספור אותו. עכשיו אחרי שהוספנו אותו ל-dictionary אנחנו רוצים לבדוק אם הוא חורג מהקווטה, אם quest counts במיקום IP יותר גדול מה-daily quota.