Hi Bob, On Thu, 27 Mar 2003, Bob Woodside wrote:
> I'll grab the new tarball first thing in the > morning...or whenever I find out the URL for it. I created a subdirectory for the tarballs: http://www-user.tu-chemnitz.de/~uwp/fvwm-web/packed/ I have checked fvwm_php_28032003_0809.tgz twice and untared it in a test directory. > In PHP4 all the Environment, GET, PUT, Cookie, and > Server variables that were implicitly global before are > contained in global arrays, like $HTTP_SERVER_VARS (4.0, > now deprecated) or $_SERVER (4.1 and later). In addition, > since 4.1 these "Superglobal" arrays are implicitly > global; the old $HTTP_xxx_VARS had to be declared global. > Finally, there is a Superglobal array called $_REQUEST > that contains all the variables "provided to the script > via any user input mechanism, and which therefore cannot > be trusted" - e.g., the POST and GET variables, etc. Sounds resonable. > The register_globals = On setting makes all these > variables automatically appear in the global space. So if > someone requests http://my.host.com/mypage.php?decor=xp > you automatically have a variable called $decor in your > global space, just like in PHP3. With register_globals = > Off, you don't have all these variables in your global > space. If you want a $decor variable input via the URL, > you have to do something like $decor = $_REQUEST['decor'] > or $decor = $_GET['decor']; and if you want it to be a > global, you have to declare it as such. > > Basically, turning it off forces you to think about > where a variable is coming from, and whether it's global. > The idea is to minimize "variable poisoning". For > example, suppose someone requests the URL > http://my.host.com/mypage.php?PHP_SELF=someboguspagename, > then where did the value of $PHP_SELF come from? $_SERVER > is guaranteed to contain only the Server variables. > > It's off by default, and the documentation strongly > recommends leaving it that way unless you really need it > on (probably because you're running a lot of older code > that depends on the old behavior). I like that concept since it forces me to think about what I am doing. It reminds me on the type concept of java. Thanks very much for this explanation. I think it is not that much effort to convert the actual php-files that they work with php4 and this settings. > I'm not sure when the CLI version was introduced - > somewhere in PHP 4. Ah, the manual says 4.2.0. I am going to grab 4.3.1 today. I have not compiled a php-module yet - hope there will be not that much problems to get this work with my actual apache installation ;-) Maybe I need to upgrade my apache server to version 2 as well. > if (isset($_GET['decoration_path'])) { > // Do any sanity checks on the value here...is it ridiculously > // long, does the directory exist, etc. > $decoration_path = $_GET['decoration_path']; > } else { > $decoration_path=$rel_path."/decorations/window_deco_simple_blue"; > } > > Or, you could use $_REQUEST instead of $_GET if you don't > care whether it came from GET or POST. In our case, of > course, it's always a GET variable. I could do that changes when php4 is running on my machine. Or if you like you could do that as well - let's see who is first :-) Regards, Uwe -- ,_, Uwe Pross (O,O) mailto:[EMAIL PROTECTED] ( ) http://www.tu-chemnitz.de/~uwp =-"-"-================================ -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
