Hi,
Version 1.6.03
I use a custom header include which is specified in the Themes configuration setting.
Recently, I added some Geo IP Location code for logging and security monitoring so that every Album reference can be logged. However, it didn't work because I referred to some $_SERVER variables, and all the values were NULL!!! After poking around, I discovered that setting $STRICT=FALSE in include\init.inc.php prevents globals from being nullified.
Are there any vulnerabilities exposed by my doing that? I don't want to adversely affect CPG security, but I can't see how my using Server variables would make the program less secure. Was creating this "strict" mode actually cautionary proactive overkill by the development team?
Why are global variables nullified in the first place?
Is there a supported way to allow just the variables I want to be preserved? (eg, DOCUMENT_ROOT & REMOTE_ADDR)
I can't hard-code REMOTE_ADDR.
Thanks for any pertinent information!
Use $superCage to access SUPER GLOBALS.
https://coppermine-gallery.net/docs/curr/en/dev_superglobals.htm
Thank you ron4mac !
I had to do a little further research, but the Inspekt cage works well. One little "gotcha" was the requirement to redefine the $superCage object prior to referencing it from a different function. I can access server variables fine now. Example below (for REMOTE_ADDR), showing the prior standard variable reference commented out, followed by the current extraction from the Inspekt cage.
// Replace $_SERVER references with caged Inspekt references:
$superCage = Inspekt::makeSuperCage();
// $myIP = $_SERVER["REMOTE_ADDR"];
$myIP = $superCage->server->getEscaped('REMOTE_ADDR');
So as a result, there is NO NEED to set $STRICT = FALSE in include/init.inc.php, mooting my original question.
John,
There is a global $superCage variable that I see little issue in using, should you choose:
function myFunction ()
{
global $superCage;
$myIP = $superCage->server->getEscaped('REMOTE_ADDR');
. . . .
}
Thank you again Ron4Mac,
Your suggestion to use the global variable reference instead of creating another copy of the object should perform better.
I appreciate your support.
-JDB