As for the PRG model, on my web application I process data on the server and than I do a redirect by using header('Location: misc/page_done.php&message=1');
For manage the output, on my page_done.php I've a sort of select case when, due to the message variable value (1,2,3, and so on), I'll print the right output message to the user.
This by using GET to pass the variables to the redirected page. Could I pass this variables (in my example, the string message) trought POST instead of GET? Yeah, looks stupid, but just for curiosity...
No. Redirects forced in this manner can never result in a POST. Put the variable in a session if you don't want to show it in the URL.
The simple answer is no. Using header Location you can't pass things through post, only get.
Related
I was wondering what might be the relation between the question mark, the variable after the question mark ('show' in this case) and the way it is being passed to the GET method in PHP. Also, why don't we use POST instead of GET?
<?php
if (isset($_GET['show'])
echo $_GET['show'];
?>
<input type="submit" onClick="window.location='index.php?
show=include.inc.php'">
Oh, and the file I am working on is index.php and upon a click, it shows the content of include.inc.php.
Please help. Sorry for any stupid questions.
The question mark denotes that there is a variable to follow!
The way that the $_GET function works is by passing the variables through the URL itself! In this case, its like putting up a sign that says "Hey, show is equal to include.inc.php".
$_POST does the same, but more discreetly. Instead of passing it through the URL, it creates a little package that travels to the receiver, similar to the postal system.
I was wondering what might be the relation between the question mark, the variable after the question mark ('show' in this case) and the way it is being passed to the GET method in PHP.
The question mark indicates the start of a query string in a URL.
The URL is the only convenient place to put data in an HTTP GET request because there is no request body. An HTML form will, by default, when submitted, trigger a GET request and encode the content of the form in the query string.
PHP puts data from the query string in $_GET. It does this no matter what the HTTP request method actually was. It is a poorly named variable name ($_QUERY would be better).
why don't we use POST instead of GET?
You can't bookmark or link to a POST request.
Refreshing the page after making a POST request will prompt the browser to ask the user if they really want to resubmit the data.
In short: POST is designed for making requests which change data on the server (which don't generally make sense to repeat). GET is designed for making requests which only get data from the server (and are thus repeatable).
The code after the ? question mark is what is sent to the server in the HTTP request. (in the format: http://...URL...?key_1=value_1&key_2=value_2)
The onClick="..." code is javascript code executed when the user clicks that button in the browser.
window.location = ... is javascript code to force the browser to change the URL page to whatever it is assigned.
You can use POST instead of GET the data being sent to the server won't be as easily seen by the user in the browser, it won't become part of the URL. E.g. user can bookmark URLs with GET but not with POST data.
I would like others to explain how to ignore any input from the user that is provided through the URL?
For example; if i have a URL like viewitem.php?id=23 and if the user replaces the id with 34 i want to redirect them to an error page even if that id is available, can anyone show me how to do that?
Don't use GET variables, GET variables are easy to manipulate via the URL.
Use POST instead.
This isn't a sure fire way to prevent it, but it makes it much harder to modify the request from a browser when using POST
See also:
When should I use GET or POST method? What's the difference between them?
Question 1: URL like viewitem.php?id=23
Make use of POST method while submitting form. GET method exposes data as well as it has limititation on no of characters can be send after submit.
Question 2: i want to redirect them to an error page even if that id is available, can anyone show me how to do that?
For this check internally if the ID is available in your database if not use.
header('Location: redirect-page.php');
Ref: http://php.net/manual/en/function.header.php
I'm making a register page, signup.php, and basically what I want it to do is check for errors and if there are none, redirect to register.php. That is fine and whatnot, but register.php is the page where the actual account is made (e.g. mySQL query). Of course, in order to do that, I actually need the params gathered form signup.php. I was wondering if I could do something like this..
header("Location: register.php, TYPE: POST, PARAMS: {user,pass,email}")
Obviously I can not use $_GET as I am transmitting sensitive data (e.g. passwords).
Any ideas/suggestions?
EDIT: Thank you all for your answers. I am now storing the parameters in a $_SESSION variable.
I see no point in such redirect.
Why not to post right away to register.php?
And then check for errors and save data in database in the same register.php?
without any redirects
No, you can't, and such data would be just as insecure to any determined attacker.
Store the data in a session variable for use in the next page.
Even if this is possible, you will hit another brick wall - the implementation of redirects in the popular browsers. While the standard requires, that it asks the user if a post is redirected, all popular browsers simply interpret the redirect as a GET. In short: you can't redirect a POST that way, you'll have to find another way without a round trip to the client, or use GET.
Also, you should be aware that unless your requests are done via https, both GET and POST will present the sensitive information to any listener, as POST simply buts the query string into the http request and not the url. Security wise, both are the same.
You could store them in the $_SESSION and refer to those in the register.php page, doing some checking to make sure someone has actually filled out the information and didn't just navigate to it.
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 back 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:
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.
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.
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.
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.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.
Since application is built in such way that going Back is a quite common operation, this is really annoying to end users.
Basically, I would like to do it the way this page does:
http://www.pikanya.net/testcache/
Enter something, submit, and click Back button. No warning, it just goes back.
Googling I found out that this might be a bug in Firefox 3, but I'd like to somehow get this behavior even after they "fix" it.
I guess it could be doable with some HTTP headers, but which exactly?
See my golden rule of web programming here:
Stop data inserting into a database twice
It says: “Never ever respond with a body to a POST-request. Always do the work, and then respond with a Location: header to redirect to the updated page so that browser requests it with GET”
If browser ever asks user about re-POST, your web app is broken. User should not ever see this question.
One way round it is to redirect the POST to a page which redirects to a GET - see Post/Redirect/Get on wikipedia.
Say your POST is 4K of form data. Presumably your server does something with that data rather than just displaying it once and throwing it away, such as saving it in a database. Keep doing that, or if it's a huge search form create a temporary copy of it in a database that gets purged after a few days or on a LRU basis when a space limit is used. Now create a representation of the data which can be accessed using GET. If it's temporary, generate an ID for it and use that as the URL; if it's a permanent set of data it probably has an ID or something that can be used for the URL. At the worst case, an algorithm like tiny url uses can collapse a big URL to a much smaller one. Redirect the POST to GET the representation of the data.
As a historical note, this technique was established practice in 1995.
One way to avoid that warning/behavior is to do the POST via AJAX, then send the user to another page (or not) separately.
I have been using the Session variable to help in this situation. Here's the method I use that has been working great for me for years:
//If there's something in the POST, move it to the session and then redirect right back to where we are
if ($_POST) {
$_SESSION['POST']=$_POST;
redirect($_SERVER["REQUEST_URI"]);
}
//If there's something in the SESSION POST, move it back to the POST and clear the SESSION POST
if ($_SESSION['POST']) {
$_POST=$_SESSION['POST'];
unset($_SESSION['POST']);
}
Technically you don't even need to put it back into a variable called $_POST. But it helps me in keeping track of what data has come from where.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
Your reasoning is wrong. If the request is without side effects, it should be GET. If it has side effects, it should be POST. The choice should not be based on the number of parameters you need to pass.
As another solution you may stop to use redirecting at all.
You may process and render the processing result at once with no POST confirmation alert. You should just manipulate the browser history object:
history.replaceState("", "", "/the/result/page")
See full or short answers