send POSTDATA back and forwar how to prevent ??

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

d3ad1ysp0rk
Forum Donator
Posts: 1661
Joined: Mon Oct 20, 2003 8:31 pm
Location: Maine, USA

Post by d3ad1ysp0rk »

That's very weird. I can see maybe the browser messing up and keeping the post data alive, but it wouldn't do anything because it would be posting it to the success.php page. Are you sure you were using a 3-page system and not a all-in-one or two page system?
duk
Forum Contributor
Posts: 199
Joined: Wed May 19, 2004 8:45 am
Location: London

Post by duk »

but im wrong or if you do a check first, like every form you need a check if a user with that name already exist... right ???

so if you do that... how refreshing will inserting the same DATA to the database... im not getting the point from some ppl here saying that refreshing will duplicate entrys in DB..

this POST was mine, but i was referring other stuff, as when you do back in the browser he ask you to post again data, what i need was, try to clear the buffer becouse all POST data was inserted into SESSIONS vars and i dont need again to post DATA again... but when i go back all forms will have the data that have been sent, becouse every data is now in SESSION vars, its why i dont want to the browser when i do back to send again POSTDATA... but anyway i think i dont need more to clear the POSTDATA...
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Problem is you can't tell the browser what to do. What if a rogue site was allowed that privelege? Where do you draw the line for what a server can tell a user's browser to do?

The idea of a form token is probably most workable - its unique, can only be used once. Its also a useful practice to use on any form to prevent CSRF (Cross Site Request Forgeries) as described by Chris over on http://shiflett.org/articles/security-corner-dec2004 .

That way you can have some standard method of preventing postdata refreshes which are unintentional (or the result of forgeries). No DB required... Even helps against multiple submissions.

The key to a useable system as above (keeping in mind most invalid tokens are probably unintentional user errors) or the one Roja described elsewhere for this scenario - is to ensure it allows a redirect to a safe page. One which requires no form submission (could even be the same page if form validation is triggered by a specific POST value).
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Post-Redirect-Get pattern.

Solves the issues mentioned.
Post Reply