On Sun, August 26, 2007 6:37 pm, mike wrote: > On 8/26/07, Richard Lynch <[EMAIL PROTECTED]> wrote: >> It is *NOT* in any way, shape, or form, polluting the global >> namespace >> of all your variables, which is what register_globals is. > > That is why I said it was *one* reason register_globals was disabled - > global namespace was probably the biggest reason, but also variable > overriding and sloppyness allowing for exploits was probably up there > too.
I'll say it again: regsiter_globals has *NOTHING* to do with $_REQUEST. Zero. Zilch. Nada. Zip. >> There could easily be a script written which is expected to respond >> to >> GET or POST data in the same way, particularly a simplistic >> web-service that doesn't really care if the web "Designers" prefer >> to >> have buttons or links or CSS links that look like buttons or CSS >> buttons that look like links or rabid squirrels that send the GET >> and/or POST data to make the HTTP request. > > Yes, there could. But part of that would rely on a *very* motivated > end-user (or we'll call them "hacker") - they would probably find a > way in or do what they want either way. No, it only relies on one "Designer" who wants their request to look like a FORM and another "Designer" who wants their request to look like a link. And I don't really *CARE* if the search terms (or whatever input it its) comes from GET versus POST as there is NO Security difference whatsoever. They need equal filtration. > There's no reason to make it easier just because "well they can hack > something up to do that anyway" - that's a Microsoft approach to > security. Whatever happened to people at least trying to discourage > abuse or issues. The point is not that they can hack something up to use GET instead of POST and make it work. The point is that GET and/or POST are equally tainted data, and that I wish to provide the same services to either kind of request, and there is NO DIFFERENCE between them for this service. > I have never used $_REQUEST and my applications don't seem to have any > issues. Obviously someone could have tried to switch POST/GET on me, > but I still ensure proper bounds checking/sanity checking/type > checking/etc. But I would not allow someone to issue a GET variable to > override a cookie value without having to make the extra effort (and > furthermore understand how the variables work on the server side to > make it actually work how they want.) You're still not getting the point. There *ARE* valid reasons for allowing GET and POST to be used inter-changably. Consider a stupid simple web "service" that lets you look up Longitude, Latitude by zip code from their own website. Do you really CARE if they use a link or a form to REQUEST the long/lat with the zip input? No. You don't. So go ahead and use REQUEST. And register_globals should be off, and using REQUEST does not "undo" *anything* that was done by register_globals being turned off. >> Use $_POST when you expect the data to always be in POST data. > > correct. > >> Use $_GET when you expect the data to alwasy be in GET data. > > correct. > >> If you actually want to accept HTTP requests of either kind for >> flexibility to an external user, by all means use REQUEST. > > In my opinion a properly coded web application shouldn't be lazy and > should know the source of data. So I consider this incorrect. I'm sorry you feel that way. But please do NOT spread mis-information that using $_REQUEST un-does what turning register_globals off does. Because that is simply not factually correct, no matter how you feel about $_REQUEST. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
