I have html page where you can insert some information and then submit this form, which will change information in database. I do it normally, that submit button call php file in server.
But what I want, is that this php file will return to me the same html page of which I sent request, with modified changes. e.g: there will be "Database update successfully" text added etc.
How can I do it without AJAX ?
Thanks
In the PHP file, do a call to the header() function to redirect the user. For example:
header('Location: url.php');
To change the content of that page they are redirected to, you could pass something in the URL that your page will check for. For example:
header('Location: url.php?submitted=1');
There are other ways to implement this, but this seems the most straightforward to me. Note that you don't want to call header() until the end of your submission page.
Use POST/REDIRECT/GET
Excerpt:
The user submits the form
This is pretty straight forward. The user completes the form and submits it by pressing the submit button or enter on their keyboard.
We store the form data in a session
After processing the data we discover an error so we need to redisplay the form with an error message but we also want to populate
it with their data so they don't have to refill the entire form just
to fix potentially one little mistake. So we store their data in a
session ($_SESSION). Session variables carry over from page-to-page
for as long as the session is valid or until they are deleted. This is
an ideal place to put their information since redirecting will cause
their information to be immediately discarded by the server.
We redirect the user back to the same page using a 303 redirect
Once we have saved the user's information in their session we need to redirect them back to the same page. In order for this to work
properly we need to use a 303 redirect. This means we need to send a
303 header with our redirect. A 303 redirect will cause the browser to
reload the page without the initial HTTP POST request to be
resubmitted. This includes when the user uses the back or refresh
buttons.
We re-populate the form using the data stored in the session
When the page is sent to the user we re-populate it with their information we saved in their session.
Only by generating the whole page in CGI first, unless you go through some horribly convoluted method of getting value of one of the fields to be set to document.innerHTML or something like that in Javascript. But you'll go through hell to get the quoting issues resolved. Use AJAX, it was created for precisely this purpose and exactly to avoid the utter hell associated with what you need.
Alternatively: the "modified piece" of the page may be an iframe, and you can set the target attribute of the form, so that the PHP returns only the iframe content.
Related
I'm experimenting with JQuery Mobile by making a basic mobile app, but I've ran into an issue with passing parameters to other pages, be they separate HTML files or additional data-content:pages on the original file.
All I want to do is select a username from a drop down list, press a button, then proceed to the next page, placing the username in the header (e.g. Logged in as: Username). I've looked into multiple solutions, such as sessionStorage, PHP sessions, POST/GET from form submission, and none of them seem to work.
The closest I've got to what I want is submitting the username via POST through a form, then saving it as a PHP session variable, which displays the username on the next page, but when I navigate to another page it once again fails to display.
What is the simplest way to pass a parameter forward? I have a suspicion that it doesn't work on the additional pages due to JQuery Mobile's loading method excluding the session_start() from the header...
I also have problem with php $_SESSION in jquerymobile, here i have 4 pages
submit form, save in session
start session, display correctly, click on link
start session, nothing to display, click on link
start session, nothing to display
but it ALL WORKS with Internet Explorer 10.
I already did some test with my own program, use $_COOKIE instead of $_SESSION. Now it runs correctly in every browser with jquerymobile
Is there a way to avoid reprocessing forms when I refresh php pages? I'd like to prevent resending forms when refreshing links to php files with an insert function in them. For example, I am processing a series of notes written by users at the top of each page for a new note. Besides the obvious creating a separate php file with a header function is there another way to do it?
Use the Post-Redirect-Get Pattern.
Accept a Post request
Process the data
Issue a redirect response
Accept a Get request
Issue a 200 response
If you need to display data from the submitted stuff, then include a row id or similar in (for example) the query string of the URL you redirect to.
The best way would be to do a header("location: form.php"); call after you process the form. That would redirect you back to the form page, and if you refresh, the browser wont resend the form data.
Alternatively, you could check to see if you already processed the data received, but that would still give you the browser warning message that you are going to resend the data.
You might do both, just in case someone uses the back button and accidentally clicks Submit again.
Just set some flag when you process the form first time so you could check for it and abort reprocessing later on. Session variable or cookie will work fine.
You could put a nonce into the page that is only allowed to be used once so that if you see the same nonce come in you don't do the insert of the page.
I redirect users to a new page after processing of the form.
The form is a POST-request to do-something.php. I check the input data and if it validates I process the data and perform a redirect to do-something.php?somethingdone. So the user can hit F5 w/o resending the POST request.
I tried to use header("Location:..."), $_POST = array(), unset($_POST), but (idk why) they didn't work in my php page.
So, what I did, I just used
echo '< script>window.location.replace("http://.../this.php")</script>'
😂 it works very good! Maybe it is not a good idea, I am learning PHP for the 4th week.
I'm writing a PHP app which presents people with a form to fill out and submit.
Once the user submits the form, things change in the database and the form should become inaccessible to the user.
If, however, the user presses the back button after submitting the form, they can see it again. I have code in the back end to prevent a user from being able to re-submit an already submitted form, however ideally if the user presses the back button, they will get the same message as if they were to just navigate to it outright: A message is shown on the screen saying that this form has already been submitted and is now unavailable.
Aside from an AJAX call to the back-end to check if the form has already been submitted, and redirect the user to the "form submitted and now unavailable" message, is there any other (better?) way of handling this?
Since this will only be used internally on a SOE, I only need it to work on IE8+.
You can consider adding this information to session/cookie. Alternatively if you have authentication system, you can store this information in the database.
Probably the first option is easier and sufficient.
so basically before displaying the form you check if the cookie alreadySubmitted is 1. If yes - error message, otherwise - form. When you submit the form, just set this cookie to alreadySubmitted.
However be aware, that if someone deletes cookie, he will be able to trick your system.
Further to my previous question, here's what I decided to implement; it may not be pure P-R-G, but it seems ok. Care to comment?
The form.php has an action; let's call it validate.php.
validate.php is never seen by the user; if validates all $_GET and, if valid writes it to database and generates the HTML of a confirmation page / if not valid, it generates the HTML of an error page explaining what is wrong.
Whichever HTML is generated get stored in a $_SESSION variable and then validate.php does a header('Location: <as appropriate>);
Finally a page called submitted.php of invalid_input.php (in case the user reads the URL) consists only of echo $_SESSION['form_html'];
That seems to me like is proff against both page reload and back button problems.
Or did I goof by trying to reinvent the wheel?
Firstly, you're better off storing the form data, which means you can perform the validation again. It will also be less html. The problem with the method you're employing now is that it doesn't protect against multiple tabs, since $_SESSION is universal to a browser session.
One way I've used to prevent against duplicate submission (without PRG) is to generate a unique id for every page load (where a form is involved). When I generate that unique id, I add it to a $_SESSION['form_unique_ids'] array, and I include it as a hidden field in every form I generate. Then before I take action on a form submission, I check to see if that unique id is in the session. If it is, this is the first time that form has been submitted, and I remove it from the session. That way if I try to resubmit that page, I will know because that id is not in the session not to process the results.
This could be extended so that instead of storing a single id, you use the id as the key in the array, and let the value be the result of the transaction. Then:
If there are errors, you store the $_POST data as well. Then, redirect to original_form.php?id=unique_id and display the validation results. You can either store them or recalculate them there.
If there is success, store the success message and redirect to success_page.php?id=unique_id. Display the success message prominently there. If you like, you can remove it from the page.
You have the option of removing the session data when you display it, but that would mean if they refreshed the edit page they'd lose the validation messages and saved form data. I'd rather find a way to get rid of data that is old enough that they're not likely to need it anymore.
Anyway, some of those ideas might be useful. Then again, maybe it's way too much effort for the problem. Your call :)
As long as you use a php redirect at the end of your validate you cannot reload or back button into the validate.php
i have create a form (so it's PHP and HTML hybrid-code). it has ability to send '$_POST'. And when i click it, it work perfectly on sending and displaying input.
But there's something happening when i click Ctrl+R in firefox for represhing the page. I got this confim dialog : "To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier"
my question
what is it, (this confirm dialog ?)
what i have to do on my code so it able to suppress this dialog ?
You probably have created an HTML page that contains a <form>. The form is used to send data to the HTTP server (that is, the webserver that hosts your site).
The HTTP protocol defines different request types used to send data to the server and to retrieve data from the server. The most used are GET and POST. You must learn about all this if you want to be anything more than a very bad PHP programmer, which is unfortunately (or fortunately, if you are on the hacker side) very common.
Your problem is that Firefox has arrived on the page you are talking about after sending a POST request. If you reload the page, it has to send the same data again in the form of a POST. Due to the conventions on what a POST request should be used for (usually to modify data on a database), the browser asks the user if he is sure about what he wants to do.
There are mainly two options to circumvent this:
Change the form method to GET; or
Use a redirection after the POST.
To use the first method, you could simply add a method="get" parameter to your form tag:
<form action="senddata.php" method="get"> ... </form>
To use the second method, you simply redirect the user after the POST request, using something like
header("Location: blahblahblah")
The most used pattern is the POST-Redirect, that is, the second method I told you about. There are many security implications on using GET to change data on a database (if you are interested on that, and you should be, as every PHP programmer should, read about XSRF).
Submitting a form (sending a POST request) is commonly used to confirm an order on eCommerce sites. Therefore, submitting it twice would submit the order, twice. Therefore browsers, tend to ask for confirmation that a user wants to send the POST request again.
In order to prevent this, you need to make the refresh do a GET request instead of a POST request. To do this, simply redirect to the same page after processing the form.
header("Location: /path/to/self");
This will make it so when the user hits refresh, it will be sending a GET request instead of a POST request, and it won't prompt for confirmation.
To clairify, it goes like this:
Form gets sent via POST (User clicks on form)
Form gets processed
User gets redirected to the same page (via GET)
User now will be refreshing a GET request instead of a POST request.
I guess whenever your form (php, asps, static html etc) contains post information that may either form field infor or other, is sent to the server via firefox, it displays such a message before sending the data again to server. it serves as a security protection from Mozilla developers. I guess it can be disabled via about:config but it is not recommended to so.
Also it is a normal behaviour. It should be like this and have been like this for a fairly long time in firefox.
You may like to have a look here:
http://forums.mozillazine.org/viewtopic.php?f=38&t=682835&st=0&sk=t&sd=a&hilit=Firefox+must+send
alternatively use GET instead of POST to send your data...
Regards
If the form was submitted successfully, answer with the status code 303:
header('Location: http://www.example.com/', TRUE, 303);
This forces the browser to use a GET request for the resulting page. A reload won’t send any POST data, and no pop up is shown.