This is a discussion on any danger in overwriting $_GET ? within the PHP General forums, part of the PHP Programming Forums category; Hi, Is there any danger in overwriting the $_GET array? Will it still remain a superglobal in all circumstances? <? // ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Hi,
Is there any danger in overwriting the $_GET array? Will it still remain a superglobal in all circumstances? <? // Example 1: $_GET['foo'] = base64_decode($_GET['foo']); // modify a value // Example 2: $_GET = array(); // empty it $_GET['myNewKey'] = 'something'; // re-populate ?> I'm considering the "search engine friendly URL" methods discussed many times here and all over the web, but want to: a) maintain using $_GET, to ensure speedy conversion of old scripts b) maintain a certain level of familiarity in the way I (and others) write scripts c) have the values as superglobals (ie, available within functions) TIA Justin French |
|
|||
|
Justin French <justin@indent.com.au> wrote:
> Hi, > > Is there any danger in overwriting the $_GET array? Will it still > remain a superglobal in all circumstances? yes and yes. see below for explaination > > <? > // Example 1: > $_GET['foo'] = base64_decode($_GET['foo']); // modify a value > > // Example 2: > $_GET = array(); // > empty it > $_GET['myNewKey'] = 'something'; // > re-populate > ?> Have you tried running the script to see if $_GET['myNewKey'] actually is filled out? You'll find that it is. > > I'm considering the "search engine friendly URL" methods discussed many > times here and all over the web, but want to: > > a) maintain using $_GET, to ensure speedy conversion of old scripts > b) maintain a certain level of familiarity in the way I (and others) > write scripts > c) have the values as superglobals (ie, available within functions) Using the special name space variable rather defeats the purpose of why php now has register_globals to off. The $_GET variable should be used to ensure that the variable did indead come in from the GET request. Also malicous users can attempt to set variables that they shouldn't be setting. See "Using Register Globals" for security reasons: http://www.php.net/manual/en/securit...terglobals.php for > > TIA > Justin French > > Curt -- |
|
|||
|
On Tuesday, July 15, 2003, at 01:24 PM, Curt Zirzow wrote:
> Have you tried running the script to see if $_GET['myNewKey'] actually > is filled out? You'll find that it is. of course I tried it, and yes it works, but that doesn't mean it's smart/safe :) > Using the special name space variable rather defeats the purpose of why > php now has register_globals to off. The $_GET variable should be used > to ensure that the variable did indead come in from the GET request. > Also malicous users can attempt to set variables that they shouldn't be > setting. I'm fully aware of the reasons why one would use $_GET['foo'] over $foo, but as stated in the OP, i'm interested in using search-engine-friendly URLs like: http://example.com/article.php/cooking/154 ....rather than: http://example.com/article.php?cat=cooking&id=154 In either instance, it is possible for the end user to modify the URL to change the values, so I don't see a difference in the perceived security level of each method. Both methods require the programmer to check/validate the values, both methods pass values to a script via the URL, both methods can be 'hacked' by evil people, and both methods have limitations as to what is a valid URL. The only difference I can see is that one set of values gets placed into the $_GET superglobal array, and the other does not. My *aim* was to port the expected values in the URL (/cooking/154) into the $_GET superglobal array (eg $_GET['cat'] = 'cooking', $_GET['id'] = 154), resulting in: - less modifications to existing scripts (ie, I can still refer to the $_GET array) - more familiarity in the way the pages are coded I can't see any reason why I should not do this, and it seems to work, but I was hoping someone might have a good reason why I shouldn't... Justin |
|
|||
|
Justin French <justin@indent.com.au> wrote:
> On Tuesday, July 15, 2003, at 01:24 PM, Curt Zirzow wrote: > [...] > I'm fully aware of the reasons why one would use $_GET['foo'] over > $foo, but as stated in the OP, i'm interested in using > search-engine-friendly URLs like: Good, I was just making sure that you were aware of it. > > http://example.com/article.php/cooking/154 > > ...rather than: > > http://example.com/article.php?cat=cooking&id=154 > I do the something similar with almost all my applications I build. > In either instance, it is possible for the end user to modify the URL > to change the values, so I don't see a difference in the perceived > security level of each method. Both methods require the programmer to > check/validate the values, both methods pass values to a script via the > URL, both methods can be 'hacked' by evil people, and both methods have > limitations as to what is a valid URL. Yeah, didn't mention the security hole only when there is lack of code integrety. I was sort of under the impression that you wanted to set variables in the $_GET var to pass around for other php files to use. > > The only difference I can see is that one set of values gets placed > into the $_GET superglobal array, and the other does not. yes, global statments all over the place does make the code a bit messy. > > My *aim* was to port the expected values in the URL (/cooking/154) into > the $_GET superglobal array (eg $_GET['cat'] = 'cooking', $_GET['id'] = > 154), resulting in: > > - less modifications to existing scripts (ie, I can still refer to the > $_GET array) > - more familiarity in the way the pages are coded > > I can't see any reason why I should not do this, and it seems to work, > but I was hoping someone might have a good reason why I shouldn't... I can't either. > > Justin > Curt -- |
|
|||
|
On Tue, 15 Jul 2003 14:52:36 +1000, Justin French wrote:
>My *aim* was to port the expected values in the URL (/cooking/154) into >the $_GET superglobal array (eg $_GET['cat'] = 'cooking', $_GET['id'] = >154), resulting in: If you are on Apache, you can use mod rewrite to do this for you with NO script changes. I use this on a couple of sites, the /1/2 gets converted into "?vara=1&varb=2 in the call. Neither the search engine nor the script can tell the difference. :) |
|
|||
|
On Tue, 15 Jul 2003 07:28:37 -0500, Wendell Brown wrote:
>If you are on Apache, you can use mod rewrite to do this for you with >NO script changes. I use this on a couple of sites, the /1/2 gets >converted into "?vara=1&varb=2 in the call. Neither the search engine >nor the script can tell the difference. :) Check out this message for more info: http://marc.theaimsgroup.com/?l=php-...0319925172&w=2 |