Will bad things happen if I control the content of $_POST?

In my days of writing web applications, I'm missing a simple way for a PHP script to direct to another PHP script while passing along data without using the URL

Browsers can pass data invisibly to a PHP script using the $_POST array. So I'm devising a script that will dump the contents of $_SESSION["POST"] into the $_POST array to mimic the passing of post data, then clears $_SESSION["POST"].

For instance, a page X contains a login form. Page X directs to page Y to validate the data. Page Y discovers that the login information is incorrect, and redirects ba开发者_如何学Gock to page X - which now displays the error message "Login information incorrect" from $_POST.

Am I crazy for missing this feature? Is there some other method of doing this easily that I'm missing?

Please respond with anything that can be helpful.

You could use the session. On page X, you'd put the data into the session. On page Y, you'd validate the data and handle the redirect. You can put your error message into the session too.

The session persists between requests, so it's the perfect place to store that kind of data.

EDIT

OK, I'd do things with session variables, but if you want to avoid that you do have a few other options I can think of besides posting:

1. You can use files on the server (such as temporary files). Use the user's session key to identify which file is theirs, and you can read and write whatever data you care to it.
2. You can put the data in a database. That would work too.

Of course neither of those is a true post. If you want a true post, you have another two options.

1. First, you can return the data to the page in a hidden form, and use JavaScript to trigger a POST. This is simple to do, but it requires the data to pass through the browser. This means you'd have to take care that a user didn't change the data, and the user would have to have JavaScript on. You can checksum the data to ensure it isn't modified, but the JavaScript problem is unsolvable.

2. Another way to do it would be to take the user out of the equation entirely. When the user submits to page A, page A could make a POST to page B, check the response, and then redirect the user to the proper place. This would be just like if you had to make a JSON or SOAP call to a 3rd party service, except you control that service. It's been a little while, but I believe that HttpRequest is the class to use to do this.

It would be ideal if that URL you check with returns a simple answer ("true", "false", "yes", "no", "good", "bad", whatever), but as long as you can tell by the response whether they were successful or not, you can do it.

Now I should note that I'd agree with mvds, this sounds like a function that should be included in page A so that it can do all the work but the code can be shared with other pages. Having page A post to page B and then redirect to A or C seems unnecessarily complex. Page A can easily accomplish all this. I read your comment on his answer, but it seems there should be another way to accomplish this.

Abstract the performed actions to functions and/or classes, and the need for such kludges will vanish. Concrete: both page X and Y could call the same function to validate the posted login data.

Page X redirecting to page Y to do validation means handing back control to the client, while you could (and should) validate the data right away.