Page 1 of 1
one page for all FORM actions
Posted: Sat Jul 30, 2005 10:17 pm
by s.dot
I want to have one page that takes care of all of the actions for my site, thus named "worker.php" or something to that effect.
The idea behind this is so that all of my forms will be processed on the same page, and I'll know quickly and easily where to go to update them.
That being said, is this secure? Is there anything wrong with this idea, or is this a common procedure?
The page will process the form data, then redirect back to the previous page, thus making it never seen to the user (unless it is to provide an error message).
I've verified all my $_POST's and $_GET's, and used mysql_real_escape_string and htmlentities when necessary. I just had a concern over how secure this practice would be?
Posted: Sat Jul 30, 2005 10:20 pm
by nielsene
If your site is large, I'd be a little worried that its likely to get a little messy having all the form handlers in one file. That messiness can lead to coding errors that lead to security holes.
However, if you manage the complexity well (suitable classes/functions as your coding style dictates, even whole other chunks include'd in would help some) I don't think its really any more or less secure.
Posted: Sun Jul 31, 2005 1:59 am
by s.dot
would a 75 kb or so script, be time consuming, or anything out of the ordinary to the average site user?
Posted: Sun Jul 31, 2005 2:28 am
by josh
The only difference on the user's end would be the url they see in the 'goto' bar of their web browser. The size of the script on the server has no direct correlation with the size of the output said script generates. So no, it wouldn't be out of the ordinary for a user.
Posted: Sun Jul 31, 2005 7:16 am
by timvw
I don't like files that do everything (If you have a good policy for choosing filenames than you can find the file as easily as digging through a jumbo file anyway) It's exactly the same principle as with functions/class methods.
For example, a part of the script can handle an update of a record. So you need a choose_record, show_record, modify_record, modification_success_record and a modification_failed_record functionality. You probably end up with a jumbo switch in your script (considering you have to take care of insert/delete too)
In that case i prefer to choose an _update , _insert and _delete script. Imho, this is as clear (or clearer) then diving into a jumbo file.
Posted: Sun Jul 31, 2005 9:16 am
by s.dot
so timvw, it's a matter of preference, but you don't see anything wrong with it?
Posted: Sun Jul 31, 2005 9:26 am
by timvw
It's hard to comment on the security etc without seeing actual code, isn't it?
(As the use of every paradigm is a personal choice, i think the
KISS principle is one that is accepted by many..)
Posted: Sun Jul 31, 2005 10:47 am
by Ambush Commander
Well, from a user standpoint, having an intermediate page solves problems of a user trying to refresh a "static" page that has Post Data associated with it. For instance, for convenience, when you delete a comment from my system, you're immediately back on the same page the comment was on. If you try to refresh the page, it'll say "this page has POST variables". If, instead, it said "the post has been deleted" with nothing else, and then refreshes to another page, I don't have to worry about a hanging POST parameter.
It's not really security related.
Posted: Wed Aug 03, 2005 7:28 pm
by x01
Ambush Commander wrote:Well, from a user standpoint, having an intermediate page solves problems of a user trying to refresh a "static" page that has Post Data associated with it..
Yes, one of my main concerns when coding a website, is to keep those "refresh-post-data" out of the way.
Because is not good when you have a forum, for example, and the user posts a new topic, then refreshes the page to see if there are new replies, and gets that "post-data" warning. 99% of the times, they will continue and that can produce duplicated (or triplicated) topics.
So yes, I share your redirect solution with you. Its clean, informative and more secure.
