insert query on same page from which data is transfered - mysql

i am writing code to insert data into mysql on same page from where i retrive data by post method . it working fine but when i refresh page it will insert again.
my question is that how to stop reexcuting the insert query on refreshing page

This is being caused by the POST data being sent again when you refresh. Your browser should give you a warning that it's doing that. If you're not getting that warning, you might be using GET instead of POST which is not a good idea for actions which change or insert data.
Check your form has this attribute:
<form method="post">
If you want to avoid it altogether, just redirect the browser after the post back.
<?php
if ($_POST) {
// insert into database
header("location: thisPage.php");
// don't bother with die() here
}
Since the redirect is not being used for security purposes, and you're just redirecting back to the same page, it's not really necessary to die() afterwards.

You probably want to use the Post-Redirect-Get pattern to resolve this situation. It's good that you use POST to send data to your server. After you've done the necessary modifications, redirect your user to the page you want him to see, with a simple redirect-header. This will NOT break the back button, and a click on it will take the user back to the form, without sending the data again.

Add some variable to your form and then during saving reset it's value.
if(isset($_POST['save']))
{ //do your saving
$save="";
}

Related

How to create alert from view model

I want to validate file. While file is invalid, i want to refresh my page and inform user that he did not upload proper file. So i have this in my
views/campaign.py
try:
wb = load_workbook(mp_file)
except BadZipfile:
return redirect('campaign_add', client_id)
The only way i know how to do it is add another attribute to client class which will be
is_error(models.BooleanField())
And then change views/campaign to
try:
client.is_error = False
wb = load_workbook(mp_file)
client.save()
except BadZipfile:
client.is_error = True
client.save()
return redirect('campaign_add', client)
And with another attribute i can add in my campaign.html file some kind of if is.error is true i'm adding some kind of windows with information about bad file after reloading page. But is there any way to do it without adding another attribute?
Ok, let's imagine that the answer is a little bit complicated than you've expected.
Modern UI's are not reloading pages just to inform about some errors with user input or upload.
So what is the best user experience here?
User is uploading some file(s) from the page.
You are sending a file via JavaScript to the dedicated API endpoint for this uploading. Let's say /workbook/uploads/. You need to create a handler for this endpoint (view)
Endpoint returns 200 OK with the empty body on success or an error, let's say 400 Bad Request with detailed JSON in the body to show to the user what's wrong.
You're parsing responses in JavaScript and show the user what's wrong
No refreshes are needed. 🙌
But the particular answer will need more code from your implementation. (view, urls, template)

PHP avoid browser reposting $_POST on page refresh?

I wonder what are the techniques i can use to avoid users to post form twice when they refresh page and chose submit again?
e.g. i have form inside regiter.php and process it as well inside register.php.
1st i could process in another file e.g. register_process.php and redirect to register.php, but then i have to create about 20 new pages and relocate a lot of code, i dont want that option.
2nd i could play with headers i dont remember exact trick but had some bad experience with that - users seen old data on page after refreshing it...
3rd i could just redirect upon success to some dummy.php and from dummy.php jump back to register.php then even if they refresh page browser would not re-post, however it does not protect against them using back button and choosing re-post, i know i could expire page, but i find that annoying experience for me and probably other users to see page expired error.
4th use some unique "access key" for each form once page loaded that will post with form and once used cannot be reused, however i kind of struggle with logics of that feature. how do know key was used without storing it in MySQL DB, i think time based accesis not great either because some users can take long between page open and form submit.
I need more suggestions how to avoid users reposing form again.
Try this:
<?php
session_start();
if( strcasecmp($_SERVER['REQUEST_METHOD'],"POST") === 0) {
$_SESSION['postdata'] = $_POST;
header("Location: ".$_SERVER['PHP_SELF']."?".$_SERVER['QUERY_STRING']);
exit;
}
if( isset($_SESSION['postdata'])) {
$_POST = $_SESSION['postdata'];
unset($_SESSION['postdata']);
}
This will basically save the POST data and cause the browser to re-request as a GET request.
5th. Use AJAX or jQuery and when the form is clicked on the page submit that data in the background. Output a response to the screen. Mark that form as submitted, or save to a session, and when they refresh they will not be able to submit the form again.
In my opinion it is the best way to do it anyway. I had a scoreboard with 20 or more forms it is worked really well to send the data without refreshing. You can return a response and make the page look very professional. Using jQuery you can also use some great form validation to make sure that they are submitting the fields that are required.
I think that the best solution would be something like this:
* create a md5 or base64 of posted data
* compare this hash with a session variable (let's call it $_SESSION['repost'])
* if hashes match, skip whatever this save should do and output a warning
* if hashes do not match, or hash is not present
* assign session variable with current hash
* do whatever save should do
When you consider the first option, I don't know about the design (programming design ^^) of your website, but you should only need 1 page. Let's says you call redirect.php with all the parameters, you should call your controller and your controller should know regardless of the parameters what to do with them.
It is a good habit to be able to do some abstraction and good design when programming, it help alot in those situation.
Other way is store the last post in the session variable, and check if is equal, like this:
<?php
... program ...
if ($_SESSION['PREPOST'] == $_POST) {
// DO SOMETHING
}
... program ...
$_SESSION['PREPOST'] = $_POST;
?>

How to implement a time wait before html form resubmission?

I have an html form which inserts data into a database. I just built it.. it's very basic, as I'm just doing this to learn. In doing this, I see that I can hit the back browser button and post again.. and again.. and again.. and it keeps writing to the db.
I've seen sites where I try to resubmit info and it tells me I must wait 60 seconds (or whatever). Is this the preferred method to solve this problem? If so, how does one go about implementing it?
Or maybe you would handle it a different way?
When you insert a row, store the submission time in the table, or in the user's session.
Whenever you process the form, compare that time to the current time. If it's within 60 seconds, display an error instead of inserting a row.
There are two methods :
i) Simple client side javascript:
Store the time of last event in a javascript variable,
when the user does the event again , send an alert message about timing.
( This method can be fooled though by users knowing javascript )
ii) Store the time of last event in your database at backend when the form post is done. When the same form post is done again, check for the time, if it is allowed, do the processing, else reply with a message about the timing.

How to keep confirmation messages after POST while doing a post-submit redirect?

Hello,
I'm looking for advise on how to share certain bits of data (i.e. post-submit confirmation messages) between individual requests in a web application. Let me explain:
Current approach:
user submits an add/edit form for a resource
if there were no errors, user is shown a confirmation with links to:
submit a new resource (for "add" form)
view the submitted/edited resource
view all resources (one step above in hierarchy)
user then has to click on one of the three links to proceed (i.e. to the page "above")
Progmatically, the form and its confirmation page are one set of classes. The page above that is another. They can technically share code, but at the moment they are both independent during processing of individual requests.
We would like to amend the above as follows:
user submits an add/edit form for a resource
if there were no errors, the user is redirected to the page with all resources (one step above in hierarchy) with one or more confirmation messages displayed at the top of the page (i.e. success message, to whom was the request assigned, etc)
This will:
save users one click (they have to go through a lot of these add/edit forms)
the post-submit redirect will address common problems with browser refresh / back-buttons
What approach would you recommend for sharing data needed for the confirmation messages between the two requests, please?
I'm not sure if it helps, it's a PHP application backed by a RESTful API, but I think that this is a language-agnostic question.
A few simple solutions that come to mind are to share the data via cookies or in the session, this however breaks statelessness and would pose a significant problem for users who work in several tabs (the data could clash together). Passing the data as GET parameters is not suitable as we are talking about several messages which are dynamic (e.g. changing actors, dates).
Thanks,
M.
It sounds like type of user messaging system is needed. By this what I mean the process could look similar to the following:
The user submits the form
The system could register the user for a set of notifications/messages (store in a DB table or something along those lines.
The system send the redirect response to the user
On the next page load for the user the system would check to see if the user had any pending messages.
If they do then remove them from the pending list/table and add them to the page
This keeps you from having a page state issue while still providing the user with the messages to be displayed, note that you might need to tweak the specifics to your needs.
Hope this helps.
ASP.NET
Since the question is presented as language agnostic, you might be interested in ASP.NET's Server.Transfer which does exactly what you want to achieve.
PHP
However for PHP, the situation doesn't seem to be very easy and all solutions that come into my mind have design smells:
Sessions
Using sessions to mark your data with certain flags and then check and use them on overview page. You just have to be sure you always unset these data after you don't need them anymore, which might be tricky.
Database
Queue those data in database as confusedGeek described in his post, but I don't think it's a good idea to query every single request like this. It's going to be quite many requests on DB server if you application is bit bigger, which might slow things down.
cURL
Taking advantage of cURL in PHP, if you have the chance:
<?php
$curl = curl_init( );
curl_setopt( $curl, CURLOPT_URL, "http://localhost/something.php" );
curl_setopt( $curl, CURLOPT_POST, true );
curl_setopt( $curl, CURLOPT_POSTFIELDS, $_POST );
curl_exec( $curl );
curl_close( $curl );
?>
<form action="test.php" method="post">
<input id="textfield" name="textfield" />
<input type="submit" />
</form>
This piece of code takes something.php on server side, allows to send POST data to it and shows you its content (which could be just print_r( $POST ); in this example). This one could do what you need, but it has once again one flaw - the URL won't change, so users might get confused - and I wouldn't really recommend it.
I personally think your case might be a design flaw. Why would you want to take all resources from form page and move them to other? Isn't easier to work with your data in a file / class designed for it and then just decide what outcome you have? If something fails, it returns the user on page with form and if everything went well, you post the data to DB and show overview page with some happy message that everything went okay.
If you really want to proceed with the way of sending everything to other page, using AJAX/AJAJ could be another solution for you.

Retaining HTTP POST data when a request is interrupted by a login page

Say a user is browsing a website, and then performs some action which changes the database (let's say they add a comment). When the request to actually add the comment comes in, however, we find we need to force them to login before they can continue.
Assume the login page asks for a username and password, and redirects the user back to the URL they were going to when the login was required. That redirect works find for a URL with only GET parameters, but if the request originally contained some HTTP POST data, that is now lost.
Can anyone recommend a way to handle this scenario when HTTP POST data is involved?
Obviously, if necessary, the login page could dynamically generate a form with all the POST parameters to pass them along (though that seems messy), but even then, I don't know of any way for the login page to redirect the user on to their intended page while keeping the POST data in the request.
Edit : One extra constraint I should have made clear - Imagine we don't know if a login will be required until the user submits their comment. For example, their cookie might have expired between when they loaded the form and actually submitted the comment.
This is one good place where Ajax techniques might be helpful. When the user clicks the submit button, show the login dialog on client side and validate with the server before you actually submit the page.
Another way I can think of is showing or hiding the login controls in a DIV tag dynamically in the main page itself.
You might want to investigate why Django removed this feature before implementing it yourself. It doesn't seem like a Django specific problem, but rather yet another cross site forgery attack.
2 choices:
Write out the messy form from the login page, and JavaScript form.submit() it to the page.
Have the login page itself POST to the requesting page (with the previous values), and have that page's controller perform the login verification. Roll this into whatever logic you already have for detecting the not logged in user (frameworks vary on how they do this). In pseudo-MVC:
CommentController {
void AddComment() {
if (!Request.User.IsAuthenticated && !AuthenticateUser()) {
return;
}
// add comment to database
}
bool AuthenticateUser() {
if (Request.Form["username"] == "") {
// show login page
foreach (Key key in Request.Form) {
// copy form values
ViewData.Form.Add("hidden", key, Request.Form[key]);
}
ViewData.Form.Action = Request.Url;
ShowLoginView();
return false;
} else {
// validate login
return TryLogin(Request.Form["username"], Request.Form["password"]);
}
}
}
Just store all the necessary data from the POST in the session until after the login process is completed. Or have some sort of temp table in the db to store in and then retrieve it. Obviously this is pseudo-code but:
if ( !loggedIn ) {
StorePostInSession();
ShowLoginForm();
}
if ( postIsStored ) {
RetrievePostFromSession();
}
Or something along those lines.
Collect the data on the page they submitted it, and store it in your backend (database?) while they go off through the login sequence, hide a transaction id or similar on the page with the login form. When they're done, return them to the page they asked for by looking it up using the transaction id on the backend, and dump all the data they posted into the form for previewing again, or just run whatever code that page would run.
Note that many systems, eg blogs, get around this by having login fields in the same form as the one for posting comments, if the user needs to be logged in to comment and isn't yet.
I know it says language-agnostic, but why not take advantage of the conventions provided by the server-side language you are using? If it were Java, the data could persist by setting a Request attribute. You would use a controller to process the form, detect the login, and then forward through. If the attributes are set, then just prepopulate the form with that data?
Edit: You could also use a Session as pointed out, but I'm pretty sure if you use a forward in Java back to the login page, that the Request attribute will persist.