Re: [PHP] $_REQUEST or $_POST?
[EMAIL PROTECTED] wrote: > I've learned to use $_REQUEST but it seems to me that it uses any $_GEt, > or $_POST. Is it better to $_POST when I'm just using $_POST? It seems > like that if I want "good code", but I mean is it faster with $_POST? Not faster. Maybe cleaner, if you only want to allow $_POST, or $_GET as appropriate. $_REQUEST also contains all of $_COOKIES as well. I use $_REQUEST when I *want* the script to respond to $_GET / $_POST because I expect other folks will find it useful as either a link or FORM from their own sites. Guess I'm breaking some rules about the GET only retrieves though, in some places, maybe... Though, really, GET logs all kinds of stuff, and maybe you are user-tracking and whatnot, plus session time-stamping all "changes" stuff, so where does one draw the line? -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST or $_POST?
--- [EMAIL PROTECTED] wrote: > I've learned to use $_REQUEST but it seems to me that it uses any > $_GEt, or $_POST. Is it better to $_POST when I'm just using > $_POST? It seems like that if I want "good code", but I mean is it > faster with $_POST? It's not faster, but it is a better practice. It is also particularly helpful for avoiding certain types of common attacks, because it allows (forces, actually) you to keep up with the exact origin of data. This is also important in adhering to the HTTP specification which states that GET requests should not perform any action other than retrieval. Hope that helps. Chris = Chris Shiflett - http://shiflett.org/ PHP Security - O'Reilly HTTP Developer's Handbook - Sams Coming Soon http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST
Benjamin Edwards wrote: I am kind of assuming that $_REQUEST is and aggregate of $_POST, $_GET and $_FILES. Is this correct or are there differences. It's a combo of $_GET, $_POST and $_COOKIE. -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals – www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST
Be carfull with this super var. This var is a merge of the GET, POST and FILES, and so only 1 index can only exists. If you have an index in the POST field called 'test' and also and index calles test in the FILES or GET var, than only one index of them is avaible and the other are gone I recommend to use the GET, POST and FILES var instead of the REQUEST var.. Am Montag, 10. Januar 2005 13:33 schrieb Benjamin Edwards: > Trying to get my head around relationship between/use of $_GET, $_POST and > $_REQUEST. > > It seems to me that $_REQUEST is most useful as if it is used in place of > $_POST/$_GET it would be possible to change posting method without changing > the code. > > I am kind of assuming that $_REQUEST is and aggregate of $_POST, $_GET and > $_FILES. Is this correct or are there differences. > > Ben -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_REQUEST
[snip] there seems to be a limit to how many form variables I can get wtih a $_REQUEST. does anyone know how to get an large amount of variables? [/snip] Look at $_POST -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_Request from 4.3 to v5.x
If you turn off notices in your app, you won't get that. error_reporting = E_ALL & ~E_NOTICE Or, you could use isset to make sure that it was submitted (best option). $searchtype = isset($_REQUEST['searchtype'] ? $_REQUEST['searchtype'] : false; On Wed, 14 Jul 2004 00:18:22 +1000, Michael Purdy <[EMAIL PROTECTED]> wrote: > Folks > > I am currently using 4.3.7. > > I have a script which accepts three POSTed variables from a basic form. Under 4.3.7 > the script > runs fine and the variables are successfully passed to the script. > > I am testing 5.0 C3 and receive the following error > > PHP Notice: Undefined index: searchtype in c:\http\cgi\list7.php on line 13 > >
Re: [PHP] $_Request from 4.3 to v5.x
Michael Purdy wrote: I have a script which accepts three POSTed variables from a basic form. Under 4.3.7 the script runs fine and the variables are successfully passed to the script. I am testing 5.0 C3 and receive the following error PHP Notice: Undefined index: searchtype in c:\http\cgi\list7.php on line 13
Re: [PHP] $_REQUEST non populated
Marek Kilimajer ha scritto: variables_order - usualy set to EGPCS It's already EGPCS, I'm waiting more info from the system administrator of that server. Is there any enviroment variable that may help to solve this problem? I don't want to post the entire phpinfo :-) Thanks Andrea -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST non populated
Andrea Pinnisi wrote: I've made a php script that works fine on many servers, but in one of them I get $_REQUEST not populated, if I print_r($_REQUEST) I get my cookies, and not GET or POST vars! I need to user _REQUEST and not _GET or _POST for some reason, and I can't change all the scripts (2Mb and more of php code, a year of work). Is there a php.ini option that can help me? variables_order - usualy set to EGPCS -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST???
>Considering all of this... Would it be better simply to turn >register_globals = On if the vast majority of the stuff you have on your >site is simple search engine type stuff and/or GET variables? That's the reason why register_globals was originally ON. Actually, going way back, I don't think you could even turn it OFF at all... It's just *S* convenient. >Considering the fact that anyone can forge GET, POST, & cookies, is there >really any purpose in turning register_globals = Off ?? *YES* Consider the following (stupid but common) code: Now, with register globals on, if I visit: http://example.com/valid=1 Game Over. In theory, nobody would ever have a variable they were using that was uninitialized because they set error_reporting to E_ALL (like they should) and they completely test every line of code and branch of logic in their application (like they should)... Here in the Real World, there are a zillion scripts "out there" by non-programmers (hey, PHP *is* that easy!) and they have Security Holes like this in them. Some of these are (or at least were) in widely-distributed third-party PHP applications, as I understand it. :-( Turning register_globals ON will make the above hack to pass in $valid through GET as a "global" not work. Stops the hack cold, because $valid isn't allowed to "sneak" in through the URL any more. You could say "register_globals OFF increases the security of a badly-written application" :-) This "register_globals" has *nothing* to do with "global" in functions, just in case the terminology is making anybody think they're the same thing. They're not. Not related at all. If you're an expert programmer and you *NEVER* make the mistake of using an uninitialized variable, then by all means, turn register_globals on and live happily ever after writing code without all those pesky $_GET and $_POST, or $_REQUEST if you want to treat both GET and POST data "the same" for a particular variable. If you've ever made a single mistake in your life, leave register_globals OFF and get used to the new paradigm. :-) For the record, $_GET and/or globals are *NOT* filtered in any way, shape, or form by PHP. If they *were* filtered somehow by PHP, there is *NO* reason that filter could not be applied in either paradigm. It is entirely UP TO YOU to validate the incoming data as kosher, whatever kosher means in the context of your application, and at the level of Security is acceptable risk to your organization, application, boss, and self-pride. Alas, PHP really *CANNOT* filter your incoming data, since there's simply no way for PHP to know what is or isn't kosher. Think about it. Try to write a generic data-validating system. It gets very messy, very fast, and it just can't be applied across the board to arbitrary data. You have to know, at a minimum, some business-logic specific information about the data. register_globals OFF *ONLY* stops the "hack" of somebody over-riding an un-initialized variable with whatever value they choose. This is NOWHERE NEAR sufficient for you to TRUST data coming from the big, bad, Internet. Disclaimer: I originally argued against register_globals OFF as default, for various reasons (not least of which is the traffic on this list from this change), and I still have it ON in many places because I actually *DO* always initialize variables. It's just an ingrained habit with me, and I daresay there truly are no uninitialized variables floating around in my personally-written code. Can't say the same for any third-party code I've installed (not much) and I *should* migrate to register_globals OFF, but I've got a *LOT* of code to fix, and there's no maintenance budget for any of it... -- Like Music? http://l-i-e.com/artists.htm Off-Topic: What is the moral equivalent of 'cat' in Windows? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST???
ðÒÉ×ÅÔ!
Patrick Teague wrote:
> Hello,
>
> Considering all of this... Would it be better simply to turn
> register_globals = On if the vast majority of the stuff you have on your
> site is simple search engine type stuff and/or GET variables?
Well, such stuff needs NOT security, nedless to say. But *any* site
needs to work properly. Besides, having the register_globals off does
not require gigantic mental efforts to get your values.
Personally I think that a register_globals off environment is educative,
in that it forces you to think about the way data gets passed a bit more
than usually. And an aware programmer is better then one who just
"believes" in the fact that his next script is gonna get the stuff it
needs.
But whether you have your register_globals on or off variable content
validation is still up to your own code, and that's where 99% of
security lies. Blocking the globals just bloks anyone from poisoning an
*internal* variable of your scripts, legally passed values must be
validated as they where before.
ÐÏËÁ
áÌØÂÅÒÔÏ
ëÉÅ×
@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_REQUEST???
> I'm not sure if it's true or not, but someone said all data coming > through _POST and _COOKIES is filtered - making it safer than pulling > the raw data from variables. Filtered? Nothing is filtered. Only you know what data the users should be sending, validate accordingly and assume all request data is unsafe. The only "filter" I see here is how the data is seperated by type, ex. only GET is in $_GET. Regards, Philip Olson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_REQUEST???
I'm not sure if it's true or not, but someone said all data coming through _POST and _COOKIES is filtered - making it safer than pulling the raw data from variables. While you're forging cookies, I'll take a few chocolate chip ;) -Original Message- Considering the fact that anyone can forge GET, POST, & cookies, is there really any purpose in turning register_globals = Off ?? This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST???
Hello, Considering all of this... Would it be better simply to turn register_globals = On if the vast majority of the stuff you have on your site is simple search engine type stuff and/or GET variables? Considering the fact that anyone can forge GET, POST, & cookies, is there really any purpose in turning register_globals = Off ?? Patrick -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_REQUEST???
ðÒÉ×ÅÔ!
Scott Fletcher wrote:
> Can the $_REQUEST be trusted?? The documentation said it is the combination
> of $_GET, $_POST, $_COOKIE & $_FILE. If the PHPSESSID is found in
> $_REQUEST, I can tell it is from $_COOKIE. I wonder if the PHPSESSID can be
> stored into $_REQUEST if hte $_COOKIE is unavailable or turned off?
>
Think of it as channels. You have 4 channels your data can come in:
1) GET (the link parameters or a form sent on the GET channel)
2) POST (a POSTed form)
3) COOKIE (data stored on the client machine IF the client machine
will accept doing that for you)
Now, as the song goes, "you only get what you give". If you tried
storing your data in a cookie $_REQUEST will have the data *only* if the
cookie worked. For you to find it in there anyway you should send it
back on multiple channels (but them why should you need a cookie when
you are sure you are going to get anyway from another channel?)
The basic weak spot in using $_REQUEST is in that people may have your
software believe that it received the input while they do send it from
another channel:
1) me disables the cookies on my browser
2) me adds ?yourCookieName=myValue on the link (or
&yourCookieName=myValue if you already have stuff on the GET line)
3) you (your software) thinks you got the cookie and uses it. What
happens next depends on the nature of data involved.
That's possible if you use the $_REQUEST. Again, it might mean nothing
in your context (that is cookie value might be absolutely irrilevant
from a security point-of-view). But it should be taken in consideration.
ðÏËÁ
áÌØÂÅÒÔÏ
ëÉÅ×
@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_REQUEST???
Are you trying to find out whether the person is logged in? You can also test the cookie with the isset function. -Original Message- Can the $_REQUEST be trusted?? The documentation said it is the combination of $_GET, $_POST, $_COOKIE & $_FILE. If the PHPSESSID is found in $_REQUEST, I can tell it is from $_COOKIE. I wonder if the PHPSESSID can be stored into $_REQUEST if hte $_COOKIE is unavailable or turned off? This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
