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
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
