Page 1 of 1

thought bug in PHP, how does a script knows ...

Posted: Sat Jun 28, 2003 10:43 am
by WildJim
thought bug in PHP, how does a script knows where it's executed?

when designing php constructions/programs, one is building a filestructure to make a project more abstract and easier to handle. moreover, it gives us the option to protect recources that can only be accessed by the php-scripts and not by a browserclient (htaccess files)

to continue further abstraction, it makes sense to build independend fully working programs and finaly bind them all together.
Sounds nice but this is where a nifty PHP design shortcomming comes in:

example START:

Code: Select all

// ...htdocs/forum/extrafile.php
<?
// put some abstract code that might be handy
?>

// ...htdocs/forum/index.php
<?
include("extrafile.php");
?>
if i call this script through a browser http://.../forum/index.php all will be running fine.

example EXTENDED:

Code: Select all

// ...htdocs/mainpage/index.php
<?
//some html preps...
echo('<tr><td>');
  include("../forum/index.php");
echo('</td></tr>'); //and a lot more
?>
The point is that the forum should be "run" visualy inside the mainpage.
My browser is now pointed to http://.../mainpage/index.php

But as you all know, the script will be "executed" (read loaded) from the wrong path for the included file. And will cause an error simply because the extrafile.php is not in the local path.

My proposal is to extend php with the option of calling a script and to execute it as if it where processed in the first case.

Only a big security problem arrises here, anyone that can upload files, can call any script at any place from inside php.

So I would propose this:

1) define a function so that a script can be called from anywhere, and it will be run in a separate process and handled as if it where run locally where the script resides.
for example

Code: Select all

// ...htdocs/mainpage/index.php
<?
//some html preps...
echo('<tr><td>');
   produce("../forum/index.php",arguments_array); 
echo('</td></tr>'); //and a lot more
?>
in the called script we now define who may call the script. as is who are the friends.

Code: Select all

<?
produce_friends(array("../mainpage/","../otherstuff/caller.php"));
...
?>

extending this idea, anonimous namespaces should be made

what do you guys think about this?
[edit]fixed a typo[/edit]

Posted: Mon Jun 30, 2003 7:27 am
by WildJim
two say it's crap, but don't argument why.

Posted: Mon Jun 30, 2003 8:25 am
by nielsene
Because there is no real need. Proper use of either include_path settings or absolute paths provide solutions to the problem you list. The solution you provide introduces a very large set of security concerns that I would prefer to avoid.

Posted: Mon Jun 30, 2003 1:55 pm
by WildJim
good, give me the example above modified so that it works not using absolute paths (witch is very amateuristic)

i tried to workout the problem and found a very drastic method to solve the problem above. As long as it isn't implementend in PHP, it will stay asside of the competition, believe me.

As a develloper, we want to build completely independend modules/components that run in a save anonimous namespace, as C++ or any other higher language would do. PHP is NOT a higher language becourse it doesn't respect these simple compiler conventions.

There is no risk involved exept the one I told. The same goes with C++ in OO. But C++ is a compiler that is run once before using the application. dll's and other techniques provide a method to extend a program at runtime. PHP doesn't provide this nature in any way.

This is what I hate about PHP, despite i love to program with it.

the biggest problem in PHP is that a namespace would be bound the moment it is executed, not when declared BIG PARADIGM!

If it would be possible to make both work then PHP would be the best to compete with ASP and others.

The solution I gave is in the mind of when one declares the "forum" module and is accessed public anyway.
The only point is that it would be excecuted in it's own relative directory and not in an outside (unknown) one