On Friday, March 1, 2002, at 07:44 AM, Team GotFusion wrote:
> What are the pros and cons of using PHP_SELF over a calling script when > manipulating data in a form? Development books show either or both with > no preference given. What is considered good form over bad? What is > technically cleaner vs. technically faster? What are the hardware > pitfalls? In developing a tutorial, we at gotfusion would like to > include these pointers or "cautions" to give our developers enough > information to make an informed decision as to which method to choose > (both methods are in the tutorial.) First of all, I always assumed (yes assume, meaning I'm not sure at all) that the reason this method is so popular is that many programmers are used to working with "stateful" environments, unlike HTTP, and in a sense, if you pass your variables correctly, this is closer to that example -- you aren't writing a bunch of separate scripts, you are writing just one that has different forms depending on how it's being called. This seems more akin to a traditional script, such as one you might encounter in Perl or Python. Secondly, I think that it is conceptually easier on the complete novice to have them be separate -- a "calling" script and a "called" script. Although it made perfect sense when I finally realized how "./randompage.php" was able to display different content depending on which "if" or "switch" statement it was in, until then I was just like "how can this ./randompage.php that I am viewing be the same page as the previous ./randompage.php ?" It was initially kind of mind boggling. I think that is the reason that Wrox's "Beginning PHP" (which I learned from) used separate pages, because it is conceptually cleaner. I think that once you have this whole single page script thing down, it's ten times easier to have one script that does a lot of code than a bunch of separate ones -- in terms of managing my data. I hate having fifty files in a directory, or a whole tree of directories to keep track of, when I don't have to. There is possibly a tradeoff in speed, however, because there is more data and info being parsed at a time. Something to consider. I don't really know. Finally, and this is kind of a weak argument for me to make, it is probably easier to send faked POST or GET data to a separate page than it is to try to send it to a single page in a different instantiation. That sounds confusing, let me re-explain what I mean: If you have a single script with a 'switch' statement, or 'if' statements, that look for specific variables before even considering the user's input (in POST data), then you are just a tiny bit more secure in that a potential attacker needs to figure out more conditions before they can try to send faked POST or GET data as "form inputs". IOW, if the user is trying to get their own data into your database, and they send a $_POST['user_id'] variable at the script, they had better make sure that they have also included whatever $_POST['action'] variable is needed to tell the "switch" statement to even look for a $_POST['user_id'] variable. Otherwise, they can send that 'user_id' variable all they want, but the code that accepts this variable doesn't care because it hasn't been "activated" by the 'switch'. This is something that is not necessarily true of a separate, standalone page, because it might not be looking for this criteria before accepting $_POST['user_id']. Of course, a good coder needs to be much more dilligent than this and anticipate this kind of thing, because this is only a further level of difficulty and not an impossibility for a clever attacker. (Obviously a clever attacker would have considered this and would be sending values for any hidden form fields on previous instances of the script, etc, to bypass the supposed security lent by the 'switch' statement.) Hope that helps, please discuss if I am off base in any of this. Erik ---- Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
