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