0

Hi folks, just a quick form question.

Whenever I have used forms in the past I have always sent the data to a seperate page to be analysed, with a 'Back' button (using history.go(-1)) to return to the form to correct any errors. When editing forms (populated from a database) recently, I have had issues with the browser requesting to resend the form data when I use the back button.
I can avoid this by sending the POST data to the same page for validation.

Are there are any security issues with sending form data back to the same page? Should I continue to display the form on one page and analyse it on another?


Zagga

3
Contributors
8
Replies
12
Views
7 Years
Discussion Span
Last Post by digital-ether
1

Zagga, yes you can still use the method you are using now where you display the data on one page and analyze it on another. Using the back button, to go back to form after submit, never really works for analyzing the data. If im not mistaken, when you fix the errors, then you have to submit again.. right? which will add another entry to the database. If thats wrong, sorry. One thing that i do is have a form page, a display page, and an editing page. This, in my opinion, would be the easiest.
ex.. page1.php

<?php if(isset9$_POST['submit'])) {
// connection
// insert to db.. $sql = "INSERT INTO.."
   if(!mysql_query($sql,$con)) {
       die('ERROR: ' . mysql_error());
   } else {
       header("location:page2.php");
   }
} ?>
<head>
</head>
<body>
<form action='$_SERVER['PHP_SELF']' method='post'>
<input type='text' name='field1' />
<input type='submit' name='submit' value='Add' />
</form>
</body>

page2.php

<?php
//connection
//dislay database
// a link to call page3 using the id
<td>".$row['field1']."<a href='page3.php?id=".$row['id']."'>Update</a></td>
?>

page3.php

<?php
if(isset($_POST['change'])) {
//connection
mysql_query("UPDATE..SET.. WHERE id = '$_POST[id]'");
header("location:page2.php");
}
<head>
</head>
<body>
<?php
// connection
$sql = "SELECT * FROM table WHERE id = '$_GET[id]'";
$result = mysql_query($sql);
$row = mysql_fetch_array($result);
?>
<form action='<?php $_SERVER['PHP_SELF']?>' method='post'>
<input type='hidden' name='id' value='<?php echo $row['id'] ?>'>
//other form fields
<input type='submit' name='change' value='Update' />
</form>

Like i said, this always works for me.. i find it the most easiest. Also, you would need to empliment a session for login in order to see "update" when you are logged in. I hope this helps.

0

Hi fobos,

Thanks for your reply, and I see where you are coming from but my situation is a little different. I'll explain.

A user logs into my site (handled with sessions) and they are shown a page that displays all the rows in their table in the database (seperate table for each user). This page only shows some of the details, but has an "edit" button next to each entry. This button sends the records ID via $_POST to an editing page.

The editing page displays all the details of the selected record, populated from the database. The user can change any data. When they submit the form, it goes to a third, processing page.

The processing page checks if everything is fine, and updates the data in the database. If there is an error in the form (a missing field, or incorrect value for example) a function in the processing page echo's the HTML to display the error, and also a "Back" button. If the button is clicked, the browser is redirected back to the editing page, which needs the id $_POSTed to it again. This means the user has to accept the form being resent, and means that any other changes they made have now been lost because the original data has populated the form again.

I think the problem is that the editing page needs $_POST data sent to it, and it doesn't get that from the processing page.
At the moment, I am using 1 more page than your method.

Is it safe (are there any security issues) to cut out the third processing page and add all that code to the editing page, so the form $_POSTs the edited data to itself to be processed? This would basically be what you suggest in your example?

In a nutshell, is it safe for a form to post data to itself.

Zagga
(Guess it's not such a quick question after all) ;)

Edited by Zagga: correction

1

The two main things here is:

1) Saving the form field values added by the user
2) Returning to the form without the "resend post" message

Saving the form field values added by the user
The only way to save the values effectively is to save them server side (or client side) and populate the form with those values when returning the user to the form.

So you can save the form values when the user submits, to their session for instance.

Returning to the form without the "resend post" message
To return without a post message, you have to use a direct link, instead of the browser back feature.
The other way to do it, is impose a HTTP redirect in between the form processing page, and the actual page displayed to the user.

So for instance when the user submits the form at form.php, you validate it on a page called validate.php, and then redirect to a page called results.php. That way, when the user hits the back button, they are taken directly back to the form.php page bypassing the process.php form submit.

0

Well if your sending it to a different page, where the data gets checked, they why dont you just use a form validator? that way you dont have to run into that problem?
Yes it is fine to have the page submit to itself. Does that answer your question? If your worried about something you could use stripslashes..

0

Thank you digital-ether,
Saving the form details in the session solves half of the problem but I'm still a little confused about the HTTP redirect (I have just been reading about REGEX though so my brain is a little scrambled) :confused:

And thank you fobos, yes that does answer my question nicely.


Zagga

0

HTTP Redirect:

header('location: /results.php');

You can redirect to a relative path, as shown or supply the full URL.

0

header('location: /results.php');

:$

So a user fills in a form on page 1 and hits send. The data is POSTed to page 2.
Page 2 checks the data then REDIRECTS the user to page 3.
Page 3 displays any errors.
If the user hits the back button on page 3 they will be taken to page 1? That doesn't make sense to me. Maybe I need to read up on redirects again.

Thanks again.

Zagga

0

Yes, that's exactly right. It is commonly used to make sure POST requests are not resent in error.

You don't have to go to three pages, you really can do it all on one page, but involve a HTTP redirect. HTTP has no notion of pages, just resources/urls and request methods. So it could be page1 -> page2 -> page1 or page1 -> page1 -> page1. As long as one is a GET, the other a POST, and the last a Redirect.

Edited by digital-ether: n/a

This question has already been answered. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.