היי חבר'ה.
כמו שאני רואה את זה יש לי שתי אופציות:

• לסנן את כל הקלט של המשתמש [POST & GET] בעזרת פונקציה שתסנן SQL INJ ו XSS. תוכן שאני צריך שלא יסונן [כמו דפים דינמים שהאדמין יוצר אשר מכילים קוד HTML] להריץ בפונקציה שתחזיר לקוד רגיל.
  חיסרון: הצורה הזו מבזבזת משאבים שכן, משתנה מסויים עובר תהליך לא נחוץ של "הגנה" והסרתה.
  
  
• לסנן רק את המשתנים שאני רוצה.
  חיסרון: הדרך לעשות זאת היא ידנית. משמע: כל משתנה שארצה לסנן אותו, אצטרך באופן ידני להריץ עליו את פונקצית הסינון.
  

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

איתי סלע,
פיתוח מערכות תוכנה ואינטרנט.

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

לפניש אני עונה הייתי מעוניין במידע של איך אתה מריץ שאילתה (באיזה אופן)?

(מפתח אתרים | iBlog - בלוג בניית אתרים)

ציטוט:

במקור נכתב על ידי iBot אני לא מוצא לנכון לסנן הרבה משאבים, בעיקר שעלול להיות זלה תוצאות לא רצויות או לחילופין ביזבוז משאבים שנראה שאתה מנסה לחסוך. לפניש אני עונה הייתי מעוניין במידע של איך אתה מריץ שאילתה (באיזה אופן)?

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

ציטוט:

במקור נכתב על ידי שימי לגבי SQL Injections - יש את השיטה של prepared statements עם PDO...

לא מכיר. אשמח אם תפרטו ..

ציטוט:

במקור נכתב על ידי GreenBerret מסכים עם שימי, ולפי דעתי זו הדרך הנכונה לעבוד עם מסד נתונים. לגבי, XSS, אני ממש לא מבין את ההייפ הזה שנוצר סביב העניין הזה. למה שתתן למשתמש לכתוב HTML ישירות לעמודים שלך??

המון סיבות, תלוי במערכת שאתה בונה. אני למשל, בונה מערכת ניהול תוכן[CMS] ובכך מאפשר למנהל האתר ליצור לעצמו את הדפים. כמובן שהוא לא כותב קוד HTML אלה משתמש בעורך טקסט עשיר[בסיגנון WORD].

איתי סלע,
פיתוח מערכות תוכנה ואינטרנט.

http://il.php.net/manual/en/pdo.prepared-statements.php

נמאס לכם לזכור סיסמאות? לחצו כאן!

אוקיי, אז למה שמנהל האתר יהרוס לעצמו את האתר?

למה שיהרוס לעצמו את האתר?
במערכת CMS אתה חייב לתת לאדמין אופציה ליצור עמודי XHTML בכוחות עצמו...
היית רוצה להגביל אותו למודולים שמתחברים למערכת?

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

חחח לא מבין אותך בכלל...

מערכת ניהול תוכן = CMS = מערכת שיש לה מודולים.
המנהל שעורך את האתר, באמצעות מערכת ניהול התוכן, יכול וצריך וחייב להיות בעל שליטה במבנה ה-XHTML של הדפים באתר שלו. משתמשים אחרים (גולשים "רגילים" באתר) לא יקבלו שליטה כזו, ולא יוכלו לערוך עמודים באתר.

מה לא בסדר כאן?

לא אמרתי שיש משהו לא בסדר, אני פשוט לא מבין מה הקשר לXSS?
למה שמנהל האתר ירצה להזיק למשתמשים באתר שלו?

למה באמת שירצה להזיק? :|
בהודעה הראשונה פותח האשכול כתב שהפונקציה מסננת XSS בתור הערת אגב אני חושב... זה לא אמור להיות בולט בהודעה...

לגבי SQL Injections - יש את השיטה של prepared statements עם PDO...

נמאס לכם לזכור סיסמאות? לחצו כאן!

איך משתמשים בשיטה הזו?

לא מצאתי שום חומר ברור ברשת.

מצד אחד אומרים שצריך PHP > 5.1.0, ומצד שני אומרים שזה אפשרי עם PHP 5.0 ...

אומרים ש"צריך להשתמש" ב:
http://il.php.net/manual/en/ref.pdo-mysql.php
אבל בעצם צריך להשתמש ב:
http://il.php.net/manual/en/book.mysqli.php

( ?? )

ואם mysqli הוא זה שצריך להשתמש בו, אז מה ההבדל בין ביצוע הדברים בצורה של הפרוצדורה לבין הצורה של המחלקה? (כאשר שתי השיטות זמינות)

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

קוד PHP:

 // placeholder must be used in the place of the whole value
$stmt = $dbh->prepare("SELECT * FROM REGISTRY where name LIKE ?");
$stmt->execute(array("%$_GET[name]%")); 


כפי שאפשר לראות, הקוד הנ"ל נמצא בחלק התחתון בעמוד הבא: http://il.php.net/manual/en/pdo.prepared-statements.php
(בשאילתא הנ"ל, כיוון שכניראה לא צריך לסנן את הקלט, הייתי יכול פשוט להכניס תוים זדוניים כמו "%" )


דבר נוסף הבנתי גם שהרצת prepared statements דרך PDO יעיל אך ורק במקרים מסוימים, לדוגמא מקרים בהם צריך להריץ את אותה השאילתא שוב ושוב, מספר רב של פעמים. דוגמא למקרים כאלה תהיה:

• UPDATE רבים
• רקורסיות המריצות את אותה השאילתא (כדי ליצור לדוגמא "עץ" של נתונים כמו התגובות בפורום)
• וכנראה אולי גם INSERT, למרות שיש לזה אופציה להכניס מספר רב של רשומות בשאילתא אחת (אבל כנראה דרך PDO זה יותר מהיר)

בכל המקרים האחרים, שימוש ב-PDO יהיה מיותר. לכן צריך להשתמש כראוי ולא כל הזמן.


דרך אגב מי שמעוניין הינה כמה לינקים שמסבירים עוד איכשהו על הנושא:

• PHP prepared statements
• http://www.petefreitag.com/item/356.cfm
• MySQL מסבירים על prepared statements
• המשפט ה-SQL'י עבור prepared statements אצל MYSQL

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

המטרה של PDO היא ליצור אבסטרקציה בין השאילתות/מידע לבין השכבה של ה DB. כלומר, אתה לא תקרא low-level ל DB מתוך האפליקציה שאתה כותב, אלא תשתמש ב PDO כמתווך. ואת זה אתה כן תעשה על כל השאילתות שלך. אחד היתרונות הגדולים ביותר, בצורת עבודה שכזו, היא, שאתה בעצם יכול לתמוך בכל DB ש PDO תומך בו, פשוט על ידי שינוי יעד החיבור של אובייקט ה PDO...

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

המטרה של PDO היא ליצור אבסטרקציה בין השאילתות/מידע לבין השכבה של ה DB. כלומר, אתה לא תקרא low-level ל DB מתוך האפליקציה שאתה כותב, אלא תשתמש ב PDO כמתווך.

האמת קשה לי להבין את זה, אולי כי אני לא מתכנת בשפות תיכנות (C וכד'...).
מה ההבדל בין שימוש בפונקציות mysql ה"רגילות" לבין PDO בעניין הזה?
הפונקציה mysql_query ומתודת ה-PDO המקבילה לה אמורות לעשות את אותו הדבר, ההבדל הוא שב-PDO אני משתמש כמחלקה.

ציטוט:

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

כלומר שעם PDO אני יכול בקלות לשנות את החיבור למסד נתונים, פעם אחת ל- ORACLE ופעם שנייה ל-MYSQL למשל. בסדר גמור, זה באמת נשמע כיתרון טוב מאוד, אבל אני מניח שהשאילתות שאני כותב לא יהיו תואמות לכל מסדי הנתונים, ואצטרך להתאים אותן אחת אחת...

ציטוט:

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

בסדר מצדיק אותך כאן, אבל תמיד אפשר לבדוק אם הוא ריק...זה לא העניין כאן.
העניין הוא אם צריך לבצע סינון על הקלט או לא. וראיתי מקומות שאומרים שצריך לבצע סינון, ולעומת זאת מקומות אחרים מרמזים שלא צריך או שאי אפשר לבצע סינון (? :/ --- כמו בפיסקת ה-LIKE, שזה חובה לבצע שם סינון, כי PDO או מסד הנתונים לא יבדילו בין המידע\קלט לשאילתא )
הנושא הזה מוסבר בצורה מאוד מבלבלת ברשת.

ההבדל הוא, כפי שכבר אמרנו:
1. הוצאת הקוד של הגישה ל DB מסויים מתוך הקוד שלך (בדומה להפרדת קוד מעיצוב?)
2. השימוש ב prepared statements שמאפשר להריץ שאילתות מהר יותר [אם הן חוזרות על עצמן]
3. הוצאת המידע שנכנס ויוצא מהשאילתא מתוכן השאילתא. גם יותר קריא, גם יותר חסין מטעויות, וגם מאפשר לך לבצע שינוי במשתנה בודד ולהריץ את השאילתא שוב (מבלי לבנות פונקציה שתבצע את זה, או להשתמש ב foreach ולרוץ על מערכים שבונים מחרוזת של שאילתא שוב ושוב)
4. החסכון ב escaping - שאולי גם עוזר ל performance (אני לא יודע אם זה באמת עוזר. יכול להיות שהוא עושה את זה בכל מקרה, אני לא יודע איך ה DB מקבל באמת את השאילתא מהלקוח במקרה הזה - אם הפרמטרים מועברים בינארית, אין צורך ב escaping. ב blob-ים גדולים זה יכול להיות משמעותי מאוד אם זה ככה...)
5. היכולת, כאמור, לשנות DB, מבלי לשנות שום דבר לאורך הקוד. כולל לא פונקציות escaping, אשר מתאימות כל אחת ל DB שלה. PDO כבר ידאג לזה...

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

מסכים עם שימי, ולפי דעתי זו הדרך הנכונה לעבוד עם מסד נתונים.

לגבי, XSS, אני ממש לא מבין את ההייפ הזה שנוצר סביב העניין הזה.
למה שתתן למשתמש לכתוב HTML ישירות לעמודים שלך?

ציטוט:

# לסנן את כל הקלט של המשתמש [POST & GET] בעזרת פונקציה שתסנן SQL INJ ו XSS. תוכן שאני צריך שלא יסונן [כמו דפים דינמים שהאדמין יוצר אשר מכילים קוד HTML] להריץ בפונקציה שתחזיר לקוד רגיל. חיסרון: הצורה הזו מבזבזת משאבים שכן, משתנה מסויים עובר תהליך לא נחוץ של "הגנה" והסרתה. # לסנן רק את המשתנים שאני רוצה. חיסרון: הדרך לעשות זאת היא ידנית. משמע: כל משתנה שארצה לסנן אותו, אצטרך באופן ידני להריץ עליו את פונקצית הסינון.

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

סינון SQL INJ אני חושב שעדיף לבצע את זה בצורה פנימית, במחלקת ה-PHP שמתעסקת עם מסד הנתונים.
אני אישית משתמש ב- sprintf כך שאני מפריד היטב בין המידע שיסונן לשאילתא.

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

ציטוט:

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

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

קישור לקובץ:

https://2009-uploaded.fresh.co.il/2...2/94004637.phps

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

השאלה היא כמה השיטה מהירה יותר. נניח מצב של טופס דיי גדול שיש 100 ערכים ב-

קוד PHP:

 $_POST 


ההבדל זניח או מורגש?

זהו שזה מאוד תלוי איזה מהקלט אתה צריך לסנן.
כי יכול להיות שהגודל מערך ה-POST הוא 1000 איברים.
אבל בתכלס אתה צריך לסנן רק 10 נניח...

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

הקובץ מכיל טעות.
בגלל קוד קטן, היעילות השתנתה מ- 550% (בקובץ הלא תקין) אל 133% (בקובץ התקין שאני מעלה עכשיו).
שמתי לב לבעיה בזכות שה- error_reporting היה במצב E_ALL ואז קיבלתי הערת E_NOTICE.

הכל היה בגלל שהשורה הבאה:

קוד:

$input += escape($_post_to_escape, $_POST);

הייתה צריכה להיכתב כך:

קוד:

$input += escape($_post_to_escape, $_POST['s']);

הקובץ התקין:
Escaping_methods.php

אפשר לעשות התפשרות בין 2 האופציות, ועוד להוסיף הרבה נוחות.

בתוכנות שאני עושה יש מחלקת SQL שעושה משהו דומה ל-Prepared statements
בנוסף לכל טבלה ניתן להגדיר שדות שהם מספרים, ולפי זה המחלקה אוטומתית תהפוך למספר בטוח

קוד PHP:

 $var = (int) $var; 


הסיבה העיקרית שאני לא משתמש ב- MySQLi\PDO הוא חוסר התמיכה ב- PHP 4.

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

אני מכיר מספיק חברות אירוח זולות מאוד שבכולן כבר יש אפשרות לבחור PHP 5 או רק PHP 5 (בלי לבחור...)...

וככל שהזמן עובר, PHP4 תעלם מהעולם. די, היא לא נתמכת יותר, ונראה לי שכבר לא יוצאים לה עדכוני אבטחה...

http://www.gophp5.org

נמאס לכם לזכור סיסמאות? לחצו כאן!

אלה לא אנשים שמבינים בזה. לא בקטע שלי להמיר את כל התוכנה שתתמוך ב-PHP 4..
כשאני יסיים את העבודה שלי עכשיו.. אני באמת יישקול לכתוב תוכנה ב- PHP5, למרות שסביר להניח שזאת לא תהיה ההחלטה שלי

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

מה דעתכם? איך אתם עושים את זה?

הרעיון טוב, אבל אל תשתמש ב-

קוד PHP:

 $_REQUEST 


אף-פעם.

ציטוט:

במקור נכתב על ידי tnadav1 הרעיון טוב, אבל אל תשתמש ב- קוד PHP:  $_REQUEST  אף-פעם.

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

לא.. אתה פשוט מקל על ההאקר לפרוץ לך לאתר.

כי הקראקר (אני מניח שלזה התכוונת, ולא להאקר) לא יכול לשלוח את הבקשה גם כ GET וגם כ POST כרצונו?

אתה רציני?

נמאס לכם לזכור סיסמאות? לחצו כאן!

אני יודע שזה שטויות...

אבל לפי איזה RFC מספר לא יודע איזה.. שימוש ב-

קוד PHP:

 $_GET 


צריך להיות רק בשביל לתת נתון להצגת נתונים (פעולה שנחשבת בטוחה..)
שימוש ב-

קוד PHP:

 $_REQUEST 


דופק את זה..

מצטער אבל לא הבנתי.

איזה הבדל יש, בשימוש בקוד, בין:

קוד PHP:

 $_GET['name'] 


לבין

קוד PHP:

 $_REQUEST['name'] 


איך הם פועלים אחרת? (למעט העובדה שהראשון לא יפעל אם הנתון ישלח בבקשת HTTP עם מתודת POST)

נמאס לכם לזכור סיסמאות? לחצו כאן!

למה הכוונה לא ייפעל...?

העלתי קובץ לבדיקת הנושא:

https://2009-uploaded.fresh.co.il/2...4/59957867.phps

כל כך הרבה קוד בשביל לבדוק האם כששולחים טופס ב POST ומנסים לקרוא את הנתונים שנשלחו דרך GET_$ ורואים אם הם מופיעים או לא?

נמאס לכם לזכור סיסמאות? לחצו כאן!

למה הרבה קוד?

מה שאמרת היה חדש לי אז רציתי לבדוק את זה כי גרמת לי לחשוב שכל הזמן הזה טעיתי.

בכל אופן, אני מניח שהבנתי אותך לא נכון, למה התכוונת?

הרבה קוד. במקום לעשות טופס ששולח מידע ב POST ולעשות פלט של print_r של GET_$ ... יש ... המון קוד.

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

כך או כך, מי שמבסס את אבטחת האפליקציה שלו על משהו שהמשתמש יכול לקבוע (כמו צורת שליחת המידע) - עושה טעות חמורה מאוד. Security by obscurity זה לדעתי תת-מקרה של חטא ההיבריס - ההנחה המטופשת שהפורץ לא מסוגל לחשוב על מה שאתה חשבת - זו יהירות.

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

במקור נכתב על ידי שימי הרבה קוד. במקום לעשות טופס ששולח מידע ב POST ולעשות פלט של print_r של GET_$ ... יש ... המון קוד. התכוונתי בדיוק למה שאמרתי. שההבדל היחיד בין שימוש ב REQUEST לשימוש ב GET, הוא ש REQUEST תמיד יקבל את הנתונים, לא משנה באיזו צורה הם נשלחו, לעומת GET שיציג אותם רק אם מתודת השליחה הייתה GET (כלומר פרמטרים בתוך ה URL). כמובן יכול להיות שאני טועה, אבל במקרה הזה, אין שום הבדל בין GET ל REQUEST - ואין שום סיבה ששניהם יהיו קיימים. כך או כך, מי שמבסס את אבטחת האפליקציה שלו על משהו שהמשתמש יכול לקבוע (כמו צורת שליחת המידע) - עושה טעות חמורה מאוד. Security by obscurity זה לדעתי תת-מקרה של חטא ההיבריס - ההנחה המטופשת שהפורץ לא מסוגל לחשוב על מה שאתה חשבת - זו יהירות.

אני שמח שעוד מישהו חושב כמוני.
חוץ מההטבות שיש לשימוש ב$_REQUEST, אין בזה שום סיכון - אם אתה בכל מקרה בודק הכל.

וכן דור כמות הקוד הייתה ממש מוגזמת זה יכל להיות 6 שורות...

ציטוט:

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

אבל הקובץ לא הראה שגם אם שלחת במתודת POST אז כל הנתונים התקבלו? <-- כך זה התקבל אצלי
התקבלו נתונים גם ב-GET, גם ב-POST... כאשר מתודת השליחה הייתה POST

ציטוט:

במקור נכתב על ידי שימי כך או כך, מי שמבסס את אבטחת האפליקציה שלו על משהו שהמשתמש יכול לקבוע (כמו צורת שליחת המידע) - עושה טעות חמורה מאוד. Security by obscurity זה לדעתי תת-מקרה של חטא ההיבריס - ההנחה המטופשת שהפורץ לא מסוגל לחשוב על מה שאתה חשבת - זו יהירות.

למה שמישהו מקצועי *יבסס* את האבטחה שלו על דבר כזה? :|
בכל מקרה אני חושב שזה לא יזיק *להוסיף* את נקיטת אמצעי הזהירות הזה.

ציטוט:

במקור נכתב על ידי שימי הרבה קוד. במקום לעשות טופס ששולח מידע ב POST ולעשות פלט של print_r של GET_$ ... יש ... המון קוד.

ציטוט:

במקור נכתב על ידי fealls וכן דור כמות הקוד הייתה ממש מוגזמת זה יכל להיות 6 שורות...

ממש לא ><
אני מתבייש לומר שהעתקתי חלקי קוד מקובץ בדיקה אחר שעשיתי....

ציטוט:

במקור נכתב על ידי dorM אבל הקובץ לא הראה שגם אם שלחת במתודת POST אז כל הנתונים התקבלו? <-- כך זה התקבל אצלי התקבלו נתונים גם ב-GET, גם ב-POST... כאשר מתודת השליחה הייתה POST

לא ניסיתי את הקוד שלך, אבל מההיגיון, ממה שאני מכיר מהעבר, ומהניסיון הזה שלי - אתה טועה.

קוד PHP:

<?php
echo '$_REQUEST = ';
print_r($_REQUEST);
echo "\n".'<br />--- $_GET = ';
print_r($_GET);
echo "\n".'<br />--- $_POST = ';
print_r($_POST);
?>
<form name="testForm" action="" method="POST">
<input type="text" name="name" value="dvir" />
<input type="text" name="subject" value="today" />
<input type="text" name="age" value="20" />
<input type="submit" name="submitTestForm" value="submit" />
</form>

הפלט:

קוד PHP:

 $_REQUEST = Array (     [name] => dvir     [subject] => today     [age] => 20     [submitTestForm] => submit )  
--- $_GET = Array ( )  
--- $_POST = Array (     [name] => dvir     [subject] => today     [age] => 20     [submitTestForm] => submit ) 


http://www.fealls.net/test.php

לרגע הבהלת אותי :s

ב-GET אין מידע כי אין URL query string במאפיין action שבתג form, ולכן המערך GET_$ יהיה ריק.

תנסה להפעיל את הקוד הבא:

קוד PHP:

<?php

define('_FILE_',basename(__FILE__));

echo '$_REQUEST = ';
print_r($_REQUEST);
echo "\n".'<br />--- $_GET = ';
print_r($_GET);
echo "\n".'<br />--- $_POST = ';
print_r($_POST);
?>
<form name="testForm" action="<?php echo _FILE_,'?get_Data=yes&amp;get_exists=1' ?>" method="POST">
<input type="text" name="name" value="dvir" />
<input type="text" name="subject" value="today" />
<input type="text" name="age" value="20" />
<input type="submit" name="submitTestForm" value="submit" />
</form>

ציטוט:

במקור נכתב על ידי dorM לרגע הבהלת אותי :s ב-GET אין מידע כי אין URL query string במאפיין action שבתג form, ולכן המערך GET_$ יהיה ריק. תנסה להפעיל את הקוד הבא: קוד PHP: <?php define('_FILE_',basename(__FILE__)); echo '$_REQUEST = '; print_r($_REQUEST); echo "\n".'<br />--- $_GET = '; print_r($_GET); echo "\n".'<br />--- $_POST = '; print_r($_POST); ?> <form name="testForm" action="<?php echo _FILE_,'?get_Data=yes&amp;get_exists=1' ?>" method="POST"> <input type="text" name="name" value="dvir" /> <input type="text" name="subject" value="today" /> <input type="text" name="age" value="20" /> <input type="submit" name="submitTestForm" value="submit" /> </form>

הרצתי, וקיבלתי בדיוק את הפלט לו ציפיתי, הנתונים שנשלחו ב POST הופיעו ב $_POST, והנתונים שנשלחו ב GET (דרך שורת הכתובת) הופיעו ב$_GET, ו$_REQUEST פשוט הכיל את שניהם ביחד

קוד PHP:

 $_REQUEST = Array (     [get_Data] => yes     [get_exists] => 1     [name] => dvir     [subject] => today     [age] => 20     [submitTestForm] => submit )  
--- $_GET = Array (     [get_Data] => yes     [get_exists] => 1 )  
--- $_POST = Array (     [name] => dvir     [subject] => today     [age] => 20     [submitTestForm] => submit ) 


כנראה שלא הבנתי נכון מה שניסית להגיד מלכתחילה - אני הבנתי שאתה טוען שלא משנה אם זה POST או GET - זה בכל מקרה יופיע בשניהם ואז אין טעם לשימוש ב $_REQUEST... תקן אותי אם אני טועה?

ציטוט:

הרצתי, וקיבלתי בדיוק את הפלט לו ציפיתי, הנתונים שנשלחו ב POST הופיעו ב $_POST, והנתונים שנשלחו ב GET (דרך שורת הכתובת) הופיעו ב$_GET, ו$_REQUEST פשוט הכיל את שניהם ביחד

אכן זה מה שהתכוונתי, זאת התופעה הנכונה.

ציטוט:

כנראה שלא הבנתי נכון מה שניסית להגיד מלכתחילה - אני הבנתי שאתה טוען שלא משנה אם זה POST או GET - זה בכל מקרה יופיע בשניהם ואז אין טעם לשימוש ב $_REQUEST... תקן אותי אם אני טועה?

מה פתאום ><
חשבתי שהתכוונתם שכאשר המתודה היא נניח POST, הנתונים במערך $_GET לא יופיעו בכלל.
הערכים של מערכי POST, GET, COOKIE, SERVER ייכנסו ל- request לפי סדר מסויים שנקבע במשתנה variables_order ב-php.ini, כאשר בברירת מחדל SERVER המשמעותי ביותר, אחריו COOKIE, אחריו POST ולבסוף הכי פחות משמעותי הוא GET. המשמעותי ביותר דורס את הערכים של הפחות משמעותי.

אז סבבה, כנראה שלא הבנת אותנו נכון

מה התחלתם לקטול אותי?

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

יש סיבה טובה למה יש הפרדה בין GET ל- POST. שני המטודות קיימות למטרות שונות.
דוגמא קלאסית זה phpMyAdmin שכל השימוש במערכת הוא רק ב- POST, ללא שום היגיון, והתוצאה היא שבכל הקטע של לעשות Refresh אתה נדפק..

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

קוד PHP:

 $_REQUEST 


דופק לך את זה.

ציטוט:

הערכים של מערכי POST, GET, COOKIE, SERVER ייכנסו ל- request לפי סדר מסויים שנקבע במשתנה variables_order ב-php.ini, כאשר בברירת מחדל SERVER המשמעותי ביותר, אחריו COOKIE, אחריו POST ולבסוף הכי פחות משמעותי הוא GET. המשמעותי ביותר דורס את הערכים של הפחות משמעותי.

את האמת עד עכשיו לא הבנתי את הקטע הזה, אבל בנוסף זה משהו שנקבע ב- ini.php, ככה שלא הייתי יותר מידי סומך על זה..

החלטתי לחקור שוב את הנושא והגעתי לכתבה מעניינת, על למה לא להשתמש ב$_REQUEST.
הסיבות הן שונות ממה שניסית להעביר, אבל הן עדיין קיימות

נמצא באשכול: למה לשקול לא להשתמש ב$_REQUEST

רק הבעיה היא שהמשמעות של RFC היא Request For Comments

אוקי.. אז אני צריך להתחיל לעבור שוב על כל המושגים האלה..

הייתי בטוח ש- RFC זה כמו התנ"ך של האינטרנט..

אז... אתה יודע.. RFC אמר..

זה לא אומר שמה שכתוב שם לא נכון, כי יש כאלו שהתקבלו כסטנדרטים...

בדיוק מה שבאתי לכתוב