none
wcf validation inspector RRS feed

  • שאלה

  • בס"ד

    השתמשתי בvalidation inspector עבור ולידציות ,

    והחזרתי את תוכן השגיאה 

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

    שרק יחזור תוכן השגיא ללא נפילה?

    בתודה מראש

    יום רביעי 20 מרץ 2013 08:22

תשובות

  • חג שמח

    לא שכחתי אותך :-) פשוט לא הייתי זמין בפורומים

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

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

    * בכל מקרה את חייבת לבצע אבטחה גם בצד הלקוח ובעיקר ובעיקר בצד השרת. נתתי שירותים לחברה שהעברתי אותם את האישורים של PCI DSS דיי בקלות למרות שהאפליקציה שם מפותחת ברמה מאוד מאוד נמוכה. הם עבדו הרבה מאוד על אבטחה של צד הלקוח מבחינת חוקי האתר. למשל בדיקות בטפסים ונתונים שהמשתמש מכניס, הרבה אבטחה ב JS שבכמה שניות או דקות אפשר היה להיכנס לקוד של הדפדפן ולעקוף הכל כי לא היתה שום אבטחה בצד השרת. על דברים כאלה בדיקות האישור של PCI לא יעלו מפני שלא מעניין אותם אם הלקוח ביצע פעולות לא חוקיות לפי חוקי האתר כל עוד הן לא בעייתיות מבחינת אבטחה כלפי כרטיסי האשראי (למשל תעבורה מקודדת).


    signature

    • סומן כתשובה על-ידי shulm יום שלישי 02 אפריל 2013 07:52
    יום חמישי 28 מרץ 2013 18:03
    מנחה דיון

כל התגובות

  • אהלן

    תבדקי אם הקישורים הבאים עוזרים לך:

    http://msdn.microsoft.com/en-us/library/ff649251.aspx

    http://msdn.microsoft.com/en-us/library/aa717047.aspx

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


    signature

    יום רביעי 20 מרץ 2013 09:52
    מנחה דיון
  • בס"ד

    בדקתי את הקישורים הנ"ל

    לא כ"כ הבנתי את תפקיד הmessage inspector 

    האם תפקידו הוא לעטוף את השגיאה שלא תהיה נפילה ?
    אם נניח הלקוח יהיה asp.net אז אפשר לתפוס את השגיאה  שחוזרת מvalidation inspector ,אך אם זה משפות אחרות יש גם אפשרות לקבל את השגיאה ללא נפילה?

    הייתי רוצה שפונקציה שמחזירה מחרוזת ,כאשר יש פרמטר לא חוקי המחרוזת בעצמה תכיל את הודעת השגיאה  

    יום רביעי 20 מרץ 2013 14:12
  • * ה message inspector הוא המנוע שמבצע את הבדיקות על ההודעות שמגיעות אל השירות. תעבורה בין הלקוח לשרת ב WCF נקראת "הודעות". ה parameter inspectors הם המחלקות המתאימות שמאפשרות בדיקה של מה שנשלח מהלקח ומה שהגיע לשרת. המתודות המרכזיות שאת צריכה הן אלו שהזכרתי בהודעה מעל.

    * יכול להיות ש parameter inspectors לא מתאים לך כל כך בשל המורכבות שלו אם את מסתבכת לעבוד איתו כרגע, אם כי הוא מכסה את כל הנושא הזה. אם כך אז יכול להיות שכל מה שאת צריכה שיכול להתאים לך זה שמתודות שלך ב WCF שמחזירות מחרוזת יבצעו תחילה את הבדיקה של מה הגיעה אליהן ואז להעביר מחרוזת שונה כולל שגיאה אם היתה שגיאה. את יכולה למשל תמיד להחזיר מהשירות גם הודעת שגיאה וגם את האלמנטים שהוא אמור להחזיר. בלקוח את תקבלי את הנתונים ואם חזרה הודעת שגיאה אז הלקוח לא ישמש באלמנטים שחזרו אבל אם הודעת השגיאה זחרה ריקה אז הלקוח יעשה שימוש במה שהגיע אליו.

    * קשה לתת הצעות ייעול שקשורות לארכיטקטורה של האפליקציה בלי להכיר אותה.

    בקישור הבא יש לך דוגמה מלאה של פרוייקט בסיסי פשוט של WCF תוך שימוש ב parameter inspectors. נסי לעזוב רגע את הפרוייקט שלך ולעבור לעומק (לבצע ולא רק לקרוא) את הפרוייקט הקצר הזה (אמור לקחת כשעה אם עוברים מהר אבל אם לוקחים את זה לעומק תוך הבנה של כל נקודה זה יכול לקחת יותר... וזה מומלץ!):

    http://msdn.microsoft.com/en-us/library/ff647875.aspx

    אני מקווה שזה יעזור


    signature

    יום רביעי 20 מרץ 2013 18:55
    מנחה דיון
  • בס"ד

    את זה כבר עשיתי בפרויקט ,נעזרתי באמת בדוגמא זו ,וזה עובד לי 

    כלומר הבדיקות והולידציות מתבצעות 

    רק מה שקורה שכאשר הלקוח מכניס נתונים שגויים חוזר לו fault exeption ויש נפילה שמכילה את הטקסט המתאים לשגיאה

    האם זו צורת עבודה נכונה ?או שאני מפספסת משהו?

    ,זה לא מוצא חן בעיני הלקוח נראה לו יותר שאמור להיות שהפונקציה תחזיר מחרוזת עם תוכן השגיאה ,ללא נפילה ,

    האם זה אפשרי עם parameter inspector?

    בתודה מראש

    יום חמישי 21 מרץ 2013 07:51
  • אני חוזר על ההצעה שלי לא להשתמש ב parameter inspector אלא פשוט לבצע בדיקות בתוכנת הלקוח לפני שליחה של הנתונים ובשירות WCF לפני ניתוח שלהם ברגע שהם מגיעים

    בכל מקרה התשובה כן זה אפשרי

    למשל בפרוייקט האמור ששמתי קישור אליו שימי לב שאם למשל המשתמש יכניס ערך שאינו מספר אז הוא יקבל הודעת שגיאה (Exception) שמקורה בפעולה של ההמרה משרשרת למספר בשורה הזו. מכיוון שזה לא מספר אז לא ניתן לבצע את הפעולה של המרה ל INT שיש במתודה button1_Click בפרוייקט של הלקוח.

                MessageBox.Show(myService.GetData(int.Parse(textBox1.Text)));

    את יכולה לבצע בדיקות בתוכנת הלקוח לפני ההמרה ולהוציא ללקוח כל הודעה שאת רוצה או כל פעולה שאת רוצה. עד כאן אין קשר ל parameter inspector

    אם המשתמש יכניס ערך מספר גדול יותר מ 5 למשל 21 אז תתקבל הודעת שגיאה של נפילת התוכנית (Exception) שמקורה במתודה BeforeCall. שהיא בדיוק החלק של שימוש במחלקת parameter inspector. במתודה זו יש בדיקה של מה הלקוח העביר לשירות.

    אם במתודה זו (BeforeCall) תבטלי את זריקת השגיאה (Exception) אז לא תתקבל שגיאה אצל הלקוח. אפשר למשל במקום לזרוק Exception לבצע פעולה אחרת כמו שינוי של הערך שהגיע מהלקוח kערך ברירת מחדל או כל דבר שרוצים ואז הלקוח לא יראה את הודעת השגיאה.

    במקום הקוד הבא:

            public object BeforeCall(string operationName, object[] inputs)
            {
                if (operationName == "GetData")
                {
                    for (int index = 0; index < inputs.Length; index++)
                    {
                        if (index == 0)
                        {
                            // execute the method level validators
                            if (((int)inputs[index] < 0) || ((int)inputs[index] > 5))
                                throw new FaultException(string.Format("Validation Input  Error: {0}", inputs[index].ToString()));
                        }
                    }
                }
                return null;
            }

    במקום זריקת השגיאה במקרה שהתנאי IF מתקיים נחליף את הפעולה בפעולה של שינוי הערך שהגיע לערך ברירת מחדל של 2 למשל כנראה כאן:

    //throw new FaultException(string.Format("Validation Input  Error: {0}", inputs[index].ToString()))
    inputs[index] = 2;

    ז"א אנחנו קובעים ערך 2 כברירת מחדל אם המשתמש בחר ערך מעל 5. ולכן נקבל את המתודה הבאה:

            public object BeforeCall(string operationName, object[] inputs)
            {
                if (operationName == "GetData")
                {
                    for (int index = 0; index < inputs.Length; index++)
                    {
                        if (index == 0)
                        {
                            // execute the method level validators
                            if (((int)inputs[index] < 0) || ((int)inputs[index] > 5))
                                //throw new FaultException(string.Format("Validation Input  Error: {0}", inputs[index].ToString()));
                                inputs[index] = 2;
                        }
                    }
                }
                return null;
            }

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

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


    signature

    יום חמישי 21 מרץ 2013 09:53
    מנחה דיון
  • בס"ד

    לפני שאני מוותרת על הparameter inspector 

    כל מה שהתחלתי עם זה כי ראיתי שזה עניין של אבטחה

    מה בעצם התועלת מבחינת אבטחה בצורה זו על פני בדיקה של הפרמטרים בפונקציה עם קבלתם?

    יום חמישי 21 מרץ 2013 11:03
  • חג שמח

    לא שכחתי אותך :-) פשוט לא הייתי זמין בפורומים

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

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

    * בכל מקרה את חייבת לבצע אבטחה גם בצד הלקוח ובעיקר ובעיקר בצד השרת. נתתי שירותים לחברה שהעברתי אותם את האישורים של PCI DSS דיי בקלות למרות שהאפליקציה שם מפותחת ברמה מאוד מאוד נמוכה. הם עבדו הרבה מאוד על אבטחה של צד הלקוח מבחינת חוקי האתר. למשל בדיקות בטפסים ונתונים שהמשתמש מכניס, הרבה אבטחה ב JS שבכמה שניות או דקות אפשר היה להיכנס לקוד של הדפדפן ולעקוף הכל כי לא היתה שום אבטחה בצד השרת. על דברים כאלה בדיקות האישור של PCI לא יעלו מפני שלא מעניין אותם אם הלקוח ביצע פעולות לא חוקיות לפי חוקי האתר כל עוד הן לא בעייתיות מבחינת אבטחה כלפי כרטיסי האשראי (למשל תעבורה מקודדת).


    signature

    • סומן כתשובה על-ידי shulm יום שלישי 02 אפריל 2013 07:52
    יום חמישי 28 מרץ 2013 18:03
    מנחה דיון