can we prevent Re-Posting of data?

Anon

hi,
when a data is posted from one file to another, and after that if you refresh the second view that is loaded after the submit button was pressed, the browser asks for Re-Posting the data.

is there anyway to prevent this? i am using a login system, which takes the users passwd and checks with db, then lets the user to move forward. and the next seen page is a frame. the frameset files actually checks the user details from db. so when user logs out, and if someone clicks the back button, and then refreshes the main frame, it enables the user to log back in without even going through the first page of passwd entry, because of Re-posting!!

any suggestions?
thanks,
Daarius...

Anon

I redirect to the next page after a form post. For example:

mysql_query("update ya-da-da-da");

// After processing, redirect to the next
// page to keep from allowing repost

header("Location: nextpage.php");

Anon

If submitting to a database, you can also create the database table in the PREVIOUS page, and then update it on the next page to insert the values.

-Ben

zalath

Hi,

I have a trick which sort of resolves the problem. I'm not quite happy with it myself, but it works.

Use sessions. You probably already do, but if you don't, do.
Now, every time a user logs off, save the session id and datetime to the database. For the logging in part, write it so that it first deletes all stored session id's over a week old (or whatever suits you). Then run a query on the database to check out if the current session id can be found, and if the query returns a result, redirect to the login page with an error message.

The idea is that after a certain session has been 'used' you can no longer log in with the same session id. This means that you're going to have to have the session id on the login page so it gets submitted too. The delete is for the simple reason that I for one refuse to believe anyone would sit next to a computer for over a week just to get to log in as someone else ;*) and simply storing them all would add to the database size considerably.

Like I said, I'm not entirely happy with this, but it's the only one I've come up with so far.

Anon

I have an extension to the same idea:

Create a table, we'll call it "input_threads".

create table input_threads (
thread auto_increment primary key,
when date)

(mysql-ish definition, here)

When you have an input form, create a record for that INSTANCE of the form: "insert into input_threads(date) values ('".date('m/d/Y h:i:s', mktime())."')";

Get the "thread" field value and put that into the input form, in a variable called "input_thread".

Then, on the receiving page, do a query to delete the input_thread, "Delete from input_threads WHERE thread=$input_thread", and get a count of the affected tuples. (mysql_affected_rows) and if ==1, go ahead with the login, otherwise spit out the login screen again.

Every so often, do a "delete from input_threads where when < $a_while_ago";
I do this at random, usually based on the clock time being exactly on the minute:

$check=date('s', mktime());
if ($check=='00')
mysql_query("delete from input_thread
where when < $a_while_ago";

Works for me. If you want to get fancy, you can include stuff like the browser version, IP address, etc. in the thread table and check these too.

I think I kinda covered this in my earlier post in this thread, but this should give more detail.

-Ben

zalath

Funny. The real solution can also be found on this site lol I found it only minutes after posting. The simple solution to prevent the repost is to use a processing script instead.

See, what you're doing now goes probably like this:

Staticpage.html -- Form w/user & pass field
script.php -- check the passwd and print something.
Now, what you should do in order to prevent this, is work around it like this:
staticpage.html -- same as above
processingScript.php -- do the passwd check, but instead of printing data print a header('Location: finalscript.php') instead.

What happens is the browser sees this as one step, not two, but it only reloads the part where the processing script redirects to the final script. Hence if you reload the form data won't be reposted, and if you hit 'back' again all you get is the form with the username and no password. Give it a try - a lot easier and more elegant than the whole database thing I had figured.

-L-

Anon

True, but that doesn't completely solve the problem.

In the original post: and if someone clicks the back button, and then refreshes the main frame, it enables the user to log back in without even going through the first page of passwd entry, because of Re-posting!!

Using header relocation doesn't solve that problem, as the user can go back to the first (static) page and hit the submit button.

Using both techniques, (header relocation, as you mention) and some kind of input thread together in tandem will completely solve the problem set.

-Ben

zalath

No, actually I think that if you test this you will find that another click of the back-button reveals the static page without the password since passwords aren't stored in the cache.

Trust me. I have a site working like this. The only way to re-post an username and password is on the next page after the form. by pressing reload, and the solution I gave effectively gets rid of that problem.

The input thread / stored sessions are far too complicated and with a larger number of users, bandwidth-intensive. Try this out before you judge me 🙂 Like I said, I had the same problem.
-L-

zalath

Oh, and by the way g if you still refuse to believe me, I'll give you an address where I implemented this solution 🙂 ...
-L-

Anon

I'm referring to preventing ANY form re-posting, you're talking about re-posting PASSWORD information.

Information stored in a plaintext field is preserved and visible when you use the "back" button even with the header redirection, and may need another protection mechanism to prevent re-post.

IE, however, doesn't save password information, obviating the need for further work.

So, in a way, we're both right... =)

-Ben

zalath

Yes, but I'm actually talking about Logging in as another user without knowing the password. Suppose you have a form with only user/password fields, it can't do much harm to know someone's username, can it?

And yes, we are both right.