On 7/7/08, Eric Butera <eric.butera@xxxxxxxxx> wrote:
> If your app is
> written correctly it doesn't matter what is thrown at it, it should
> always work. Even if a variable gets overridden it should still be
> forced to play with the rules of the app and work like a valid request
> does.
That is not an excuse to trust GET and POST for the same variable.
1) Filter your input
2) Sanity check your input/fill in your own default value if one is requied
> I think that having a set of if statements that say something like the
> following is silly.
> if (isset($_POST['id'])) {
> } else if (isset($_GET['id'])) {
> }
Oh it definately is silly. I'm saying that's a workaround if people
-had- to mix their POST/GET data.
I've never had to do it and I've coded a variety of apps, including
plenty of various pagination methods, multi-page forms, etc, etc.
For example:
# 1 - filter it, and typecast it to int
$page = $page = intval(filter_input(INPUT_GET, 'page',
FILTER_SANITIZE_NUMBER_INT));
# 2 - sanity check. a page number cannot be negative and it cannot be
greater than the number of pages (which can be determined by a db
query, or hardcoded somewhere else)
if($page < 0 || $page > $maxpages) {
$page = 1;
}
In the end $page should be trusted as it won't have any foreign data -
it has been intval()'ed and there is a default value put in - $page =
1, and there is a bounds check to ensure it's valid info.
For a better user experience, instead of setting $page = 1, I would
probably use a header("Location: foo.php?page=1"); exit(); so the
user's URL in the address bar properly matches up with the page. But
you get the idea.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
