I have a PHP form script which uses mail function. basically you write your email and the email to want to send the recommendation on the page to, and click send.
Here is the problem, once you have sent the recommendation, you can send it again, this time by refreshing the same page!
How can I make script to not remember the previous entered information by same user? flush() or something else. The script is placed in the middle of the page so I don't want the page stop executing after this php form.
Edit:
Thank you guys for your answeres, is there any script so I can use for for storing/validating IPs with help of mysql? or just a "plain text database"?
This is the web browser, not the form, that's causing this behaviour - when you refresh a page that was the result of a form submission, most browsers will offer to resubmit the data.
The usual "fix" is to submit the data to an intermediate page, then redirect the person back to the page they were viewing - that way they'd have to go back one page as well as refresh AND clicking "yes, I want to resubmit the data".
For completeness, consider only allowing a particular ip to use the "send to friend" function once per x seconds/minutes by tracking an IP's last use in a database.
For extra thoroughness, prevent a given recipient being told about a page more than once a day, or something.
Two different things you might experience:
The fact that when you go to your form the information entered previously is remebered. That is typically a function of the webbrowser (and/or the plugings installed) and not so much a problem of your script/form. That is a similar function to how your browser might remeber login credentials for you.
Typically that is not much of an issue, but you could prevent that by generating unique names for your input fields each time the form is loaded.
<input type=text name=email lenght=40>...
then becomes
<inut type=hidden uniqueID=$something>
<input type=text name=email-$something lenght=40>...
and then use the uniqueID in your form processor to reconstruct all other field names when processing the form.
Your second problem is simply that your form processor allows the same content to be processed twice or more. A common problem with common fixes.
A traditional strategy was to redirect the browser to a succes/error page after processing the form contents, which can be reloaded without any penalty. form --> formhandler page (PHP) processes form contents and sends http redirect --> success/error page.
Or more common nowadays, store the above uniqueID of the form (e.g. in a database) and refuse to process a second time.
Related
I have a submission form, and I wrote a PHP script to make form send an email with input data that the user inserts it in the fields of the form
Now I put the PHP code in the same file of HTML and CSS, I mean that the HTML, CSS and PHP in the same file
When I put the file in the CMS, that what happened to the page, you could see what happen from here: https://www.hochikiamerica.com/acd-landing-2
PHP Script and HTML code of the form
https://github.com/Mstava/FreelancerProject/blob/master/formScript.php
Now, I need to know where to put the PHP code in the HTML file to avoid this
and How to ensure that code is working and it sends the Email
When you click on submit your form action takes you to action_page.php That's where you should read your post variables and send the email. Take a look at this post I wrote several years ago blue host email
A common misconception is that additional PHP can be run upon the user doing something (i.e. clicking submit button). Not the case. When the page has been rendered, no further PHP on that page can be executed.
So, what to do?
You have two options:
(1) You can create a second page (action_page.php or some name), that is specified on the action= attribute of the form tag. That additional page will receive the data the user typed in, via PHP variables $_POST (if method="post") or via $_GET if method=get, and you can then use that data to send the contact form, and either display new data to the user or send the user back to the original page. Of course, you may need additional PHP to acknowledge the form has been sent, etc - and this additional code will need to handle both the case where the user is visiting the page for the first time, and when the contact form has been sent and the user is seeing the page for the second time.
(2) You can use AJAX (javascript/jQuery) to grab the form data, send it to a secondary PHP file, which will receive the data via the $_POST/$_GET variables, send the email, and return a response back to the first page.
These days, mostly we use the second method, because it is much more powerful. For one, the user remains on the same page. For another, there is no page refresh. For another, your javascript can do other things after the form has been sent.
AJAX is actually pretty simple - just do a google search for YouTube videos on creating a login system with PHP and AJAX. You should be able to find one of around 10 mins or less that explains all you need to know to send your contact form, and send feedback back to the calling page.
Here is a 5-minute YouTube tutorial that will show you the basics:
Install a simple PHP and Ajax login system
I've been designing a site that is used to collect data, but the person I'm designing for wants some form of redundancy just in case the window is closed or the system shuts down. Is there any way to take data that's been collected and write it to a MYSQL database if the user is disconnected for a certain amount of time, or if they shut the browser window/shut the system down without submitting the data?
The web is stateless and disconnected - so all data will (or rather: should be) persisted between page requests.
I assume you have a web-page generated by PHP that contains a lengthy data-entry form, and you want to save the data in that form in the event the user closes their browser window - the solution is to use a client-script that polls the server with the current data in the form, or at the very least hooks on to the window close event.
Actual implementation is a task left up to the OP.
This can't be done just with a pure HTML page - if the user doesn't submit the form, your server doesn't know what they've typed.
However, you could put some Javascript on the page that made an AJAX call every few seconds (or every few key-stokes or clicks). The idea would be for the JavaScript to invisibly submit the whole form to a PHP page which saved it into a sort of "holding area".
If the user then submitted the form, the holding area could be cleared out, but if they never did, then the data in the holding area would show you where they got to.
The most common techniques to partially prevent this szenario is that web apps work with a heartbeat-function which fires via javascript in a constant interval and sends a request to the server, p.e. to show that the user is still logged on - or, in your case, maybe to submit data already typed into form fields, too.
Think of it as an ajax-powered auto-save-function!
You have to add some javascript to your code for this, but the commonly used javascript libraries, like jquery or mootools, are well documented and offer alot of examples how to do something like this.
I have a form that processes a payment, but approximately one in every 300 payments comes though twice, my logs show that there were two requests for all these occurrences.
I implemented some JavaScript that disables the submit button after it's clicked, and it seems to work fine for me, but I'm still getting double submissions every now and then.
Does anyone know anything else that could be causing the form to be submitted twice?
As Dagon says, server-side checks are your friend here. Give each instance of the form a randomly generated key (guid would be nice), and store that in the database. Don't accept forms that contain a key that already exists in the db.
Also, are you simply displaying HTML after your form processing logic executes? If so, try redirecting after you process the form.
It is a way: after user presses form submit button, disable it with javascript. That should prevent user from double submitting the form accidently. It works for all sites we implement it like because. Because sometimes user gets impatient and clicks form submit button several times, thats why you get double requests. What you need to make sure it works for all the browsers (disabling the button I mean).
Also you could do it on server side, it just is harder.
We use similar to the upvoted answer in Enable/disable submit button with jQuery and Coldfusion server code
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.
What is the best way to stop a form from being reprocessed when a user hits a Back button?
I'm following the Post/Redirect/Get pattern, so I don't have a problem if F5 is pushed, but the back button still provides the opportunity to resubmit the form. If this form is a credit card processing page, this is bad.
This question has been asked somewhat here, but the phrasing and answers were of poor quality and not specific to this problem exactly.
I have form.php which submits to itself. If there were no errors in input data upon submission, the user is redirected to form_thanks.php. Hitting back (and "Send" or "Resubmit") once resubmits form.php (BAD!) and then brings them back to form_thanks.php.
Please also include solutions that do not involve using Sessions, if possible.
I would do it a different way. Put up a hidden input with a random string as the value, and when it's submitted store that random string in a session. Set up a simple check to see if they've already posted it and if they have don't accept the input.
This should be done with a single-use token, or a nonce. The php/server should include this token in a hidden form field.
It should store a list of all the recent tokens and each time a form is submitted, it should check to see if the token is in the list of recent valid tokens.
If it's not in the list, then don't reprocess the form.
If it is in the list, then process the form and remove the token from the list.
The tokens can be handled within sessions or just a simple database table without sessions. The tokens should be user-specific though.
This is also the recommended way to avoid CSRF attacks.
Just thinking out loud here. But what about a variation on post/redirect/get where the final get is not actually the final get ;) But rather, it in turn always automatically forwards to the truly final page, so that should the user hit the back button, they return right back whence they came?
EDIT:
Ok, taking into consideration the OP's comment, here's another idea. The URL for the form submission could be made to require a parameter that is good for only one use. That token would be generated (using MD5 or some such) before the form was submitted and could be stored in a database (in response to somebody else's suggestion you requested a solution without using sessions). After the form is processed, this token would then be flagged in the database as having already been used. So that when the page is returned to with the same token, steps can be taken to prevent the resubmission of the form data to the backend.
Late answer, but one could avoid the processing altogether by using an AJAX-based solution; there wouldn't be an issue with including a nonce with this processing scheme, but by using an asynchronous query which, on success, redirects the user, the requests are not repeated by refreshing, pressing back, or anything other than clicking the button.
It is also easy to implement a mechanism that prevents the button from either being pressed twice or being "locked up" if something happened during the request by embedding into the handler for the request (whether high level with PrototypeJS or jQuery or low level with your handrolled function) the mechanisms to enable and disable the button when the request completes and first fires, respectively.
I find that back will bring the form to the state it was before the page was redirected, if that is the case, have a hidden input/variable or something which starts with value say true, then once the form is submitted, and if the value is true, change it to false and then submit, else return false
Try this :
<SCRIPT type="text/javascript">
window.history.forward();
</SCRIPT>