I have a problem with POST and I hope someone can help me. I have two pages, A and B. I need to send some data through POST from A to B, and B can't be modified in any way. How can I send my POST data from A to B, using PHP? The thing is: I don't need to just send the data, I need to go to the page as well, while sending the post, since B creates a cookie that I need.
header + curl? fsockopen? curl only?
not entirely sure what you are asking, or if i am simplifying it but check out this:
http://www.w3schools.com/php/php_post.asp
If all you need to do is send data from page A to page B and then navigate to page B, then set the action of the form to page b, so when you hit the button, you will navigate there.
If something is just too complicated, maybe you're going on the wrong way.
Why do you need such a thing? Can't you just redirect to that page using a form with action="post"? This is the most used way to do what you want, almost every site use this.
If not, tell us the real problem, what you said is a solution to a problem.
Basically you need to create a form and set the action to equal B and the method to 'POST', and then have the data you want to send in input tags and don't forget to give each input tag a name and then add a submit button.
When one clicks on the submit button it will send the data to page B and transfer you to that page
Your question is little unclear .
In page A, you need to set the form action for example then you can get your values in page B and also you will navigated to page B
If you need the cookies fro a different domain to be set to a client / visitor, you'll have to get them there, which essentially means they will have to do the post (doing it with curl from you own server still leaves you with no way to set the cookies). The only feasible solution I can see is to perform a post with client-sided scripting (i.e. javascript).
You cannot let the user do a POST with PHP. Period, no way whatsoever. Sure, you can post from your own server what you like, but it won't do a lick of good as long as you cannot get the cookie information to the client, which you can't due to browser security / privacy issues.
Related
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'm a bit confused. How do I POST data to a URL and then redirect the user's browser to that location - all in one operation?
I see
header('Location: page.php?' . http_build_query($_POST));
but that is GET, not POST and ppl think thats really bad practice - PHP open another webpage with POST data (why?)
My kludgy workflow involves setting up a form and then submitting it via javascript - anything has to be better than that...
I think I can do a set of header() stmts but this action happens for the user way after the page has been geenrated, so i dont think that would work
You cannot redirect POST requests. As simple as that. Any redirect will always turn into a GET request.
If you want to receive POST data, then send that data to another page, you have two choices:
if both pages are on the same server, use sessions to save the data server-side, don't make the client carry it over
if the destination is on another server and you need to send the client there together with the data, set up another intermediate form like you are
Use AJAX to save the data before you leave the page. Use the answer you get back to fire a redirection to the new url right within the current page. Don't be affraid of Javascript and ajax. Try this light AJAX library: http://www.openjs.com/scripts/jx/
I am doing my work in PHP.
I have 3 pages,
A is plain HTML and contains a search field.
B is .php and returns results of the search.
C is also php and allows user to update some details for the displayed results.
When I'm doing Refresh my B page or Go-Back from C to then I
get this message
"To display this page, Firefox must
send information that will repeat any
action (such as a search or order
confirmation) that was performed
earlier."
I saw "When i'm using "POST" method then I get this message, if I'm used GET then
I don't.
Any buddy Explain me ,why???
The GET method should be used to obtain information from a web page.
The POST method should be used to send information to a web page.
The reason it asks you to confirm whether or not to send information again is because it's not always the user's intention to repost a form if they press back. One example is at an online store, you would not want to repost a form to purchase a product twice, otherwise you could be billed for the product twice. This is theoretical of course since someone who makes an online store should ensure that an accidental purchase can't happen.
Also, if you use GET, then all information is appended to the URL of the PHP page. This is a potential security issue, especially if the form contents are private. For such forms, you should be using POST.
A wild guess,
POST is not written in the URL, so you need to resend it, while GET, when you click to return to B, the arguments are still in the URL so you dont need to resend.
Mozilla added this message to warn you from sending the information twice.
Like in the form of registration, you don't want to register twice.
Firefox developers added that warning for POST method. It will warn you for POST in case of back/forward also.
This is an added safeguard for users. Because, most shopping carts/banking portals use POST method for checkout/transaction confirmation (actually I have not seen or developed any web app to use get method for this purpose).
So, Firefox (and most other common browsers) warn you in this scenario (when your are sending POST request indirectly, i.e. using back/forward/refresh button). This prevents the user from multiple checkout.
Another reason to add this warning is, sometimes chekout is time consuming. So, when some time is passed after the original submission, some impatient users think that the browser/server has stopped working. So, they tend to press the refresh button. This warning gives them a good hint.
I think the point is that GET requests should be used to get information without changing anything on the server so if you reload the same information there's no issue. POST requests should be used to change data on the server so when you reload the page that may have undesirable effects.
Firefox should normally allow you to navigate back to your B page from your C page. However if your B page is not in the cache, possibly because it sends a Cache-control: no-store header, then you will get the POSTDATA warning.
On the other hand explicitly reloading page B will always generate a POSTDATA warning.
When you submit data in the POST method, it sends headers to the page you submit to. When you refresh the page or go back, your browser repeats your POST request and Firefox warns you of this.
I have a html file that has two buttons, approve and reject. I want that if someone clicks on the approve button, I want the box to disappear and display a message PERMANENTLY.
By permanently I mean that it should not return the box when I refresh the page.
Is it possible with JS or PHP or anything else?
Thanks.
Is it possible with JS or PHP or anything else?
Yes.
For a more detailed answer supply a more detailed question.
Uhm, presumably when someone clicks one of those buttons, you store a value somewhere indicating their action. You would normally check if the user has previously performed this action (or if it otherwise makes sense to display the buttons) and just not output them from your PHP script in that case.
Without more details about your code it'll be impossible to provide any more help than this.
You either need to store a cookie that you can check if they clicked or you need to store a list of IP's and what they clicked. That's the hard part
Hiding and displaying the box is as easy as using jquery and the onclick element in html.
Edit:
I agree with the above answer without more details it is hard to provide a working solution.
js will not be able to do something like this by itself. you need some sort of back end server processing or a cookie that will detect the user when they go to the page and then save their button click in a server side db or client side cookie... then when the user comes back it checks the back end data source or the client side cookie and makes the changes either client side with js or server side with php
I expect you'll need to set a cookie when you put up the message. That's only permanent as long as they keep the cookie, though. For real permanence you'll need to associate the message state with their login/customer info and retrieve that every time they come back to the site. Which means you'll have to force a login before they get to the form.
The problem with trying to do something dynamic, then make it permanent, but only for that user, is that you have to get over the statelessness of the web. You have no idea who you're dealing with from one visit to the next. To get over that, you either need to tag them (by setting a cookie) so you'll recognize them on their next visit, or you need to make them identify themselves (by forcing a login).
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