Codingtips

Before being POBSed, you probably need to adjust your sourcecode here and there. Especially in case you have chosen to also replace variables. In a scripting language like PHP, variables may create most of the problems. Below are some problems and solutions.

Don't name constants after HTML tags
POBS finds it hard to really find the constantnames. Contrary to variables, constants in PHP do not start with a indicator like a dollar-sign ($). If you have defined constants with names like "HTML" or "HEAD", POBS will replace both these constants and these HTML tags with a new name, thinking they are constants. In order to avoid this, simply start every (or at least every dubious constantname) with a "c". I personally find it good practise to use uppercase for each constantname except for the first letter. So something like cUSERNAME and cHEAD. This will generally prevent problems.

Check for parse_str
"parse_str" is useful PHP function which scans a string (i.e. a query_string) and generates variables. So a string with "Var1=3&Var2=X&Var3=123" processed by parse_str would result in the declaration of 3 variables and the according values would be assigned to them.

This is particularly useful when passing many parameters to a certain function.

I.e. function ProcessStuff($ParamsStr) {
parse_str($ParamsStr);
If ($Var1==4) echo "Yes";
If ($Var2=="X") DoThis() ;
If ($Var3==999) echo "Very much";
}

ProcessStuff("Var1=3&Var2=Y&Var3=456);

The example above would go wrong if been processed by POBS. POBS deals with the problems posed by functions like parse_str. POBS not only replaces $Var1 with a new name but also all occurences of &Var1. In the example above, Var2 and Var3 would do fine but Var1 would go wrong. POBS will replace $Var1 but will not replace Var1 in the parameterstring since it is not preceded by an ampersand (&). To avoid this problem simply add a preceding ampersand to the first variable in the parameterstring.

ProcessStuff("Var1=3&Var2=Y&Var3=456); is wrong

ProcessStuff("&Var1=3&Var2=Y&Var3=456); is right

Dealing with set_error_handler("<functionname>");
If you use the function set_error_handler("myErrorHandler") "myErrorHandler" is the name of a function. POBS will replace the functionname everywhere except when used as a parameter for this function. So you will have a problem. To avoid it, add the appropriate functioname (i.e. "myErrorHandler" ) to the $UdExcFuncArray in the pobs-ini.inc.php file.

In future versions of POBS this problem will be dealt with.

Double slashes and comments removal
Removing comments from your source code obviously helps in preventing others using it. You can optionally instruct POBS to remove comments. This should only be done after everything else is obfuscated and your POBSed program works.

In order for POBS to find comments it searches for double slashes in your code preceded by a space or tab character (like " //"). It does not (yet?) check whether these slashes are somewhere in between quotes (in case they would not be comments). This could give you a problem in case you have something like:

header("Location: http://pobs.mywalhalla.net);

in your code.

But since the double slashes are not preceded by a tab or space here, POBS will not consider //pobs.mywalhalla.net a comment.

Dealing with $$Var1
Consider the following code snippet:

$Var1="Var2";
$$Var1="Amsterdam";
echo $Var2; // "Amsterdam"

$Var2 will have the value "Amsterdam"

POBS makes the following code of it:

$V31bff649="Var2";
$$31bff649="Amsterdam";
echo $V8c4e34d5; // empty

As you see POBS has replaced all occurences of $Var2 but not Var2. Therefore this little program will not work as intended. To get it working you need to add Var2 to the $UdExcVarArray in pobs-ini.inc.

Dealing with $GLOBALS and $HTTP_POST_VARS
$GLOBALS is a predefined array in which all the global variables are present. In many programs variables are added to this array.

POBS replaces both $Var as $GLOBALS["var"] or $GLOBALS[var] occurences in your code so this will generally not cause problems. But you might have a strange unusual situation with i.e. $GLOBALS[strtolower($VarX)] where POBS will not work properly. You would have to add $VarX to the exclude user-defined variables array in pobs-ini.inc.

From version 0.92 POBS does also deal with $HTTP_POST_VARS, $HTTP_GET_VARS and $HTTP_COOKIE_VARS.

Forms and fields
If a user submits a form that is given to a PHP script, PHP automatically creates variables with names corresponding with the names of the input fields of the form.

POBS deals with this by also replacing every field in every form

So, consider the following HTML code:

<FORM METHOD=POST ACTION=do-it.php>
<INPUT TYPE=TEXT NAME=address>
<FORM>

The PHP script do-it.php has references to $address. POBS will replace it. And POBS also replaces NAME=address with that same value.

A problem arises when a program outputs forms automatically. POBS can no longer find code like :

echo "<INPUT TYPE=TEXT NAME=address>";

but will instead find something like:

echo "<INPUT TYPE=TEXT NAME=".CreateFieldName("address").">";
or
echo CreateFieldName("address", cTEXT);

and will not replace the fieldnames.

The remedy would be (that's what I did) to let all created fieldnames by CreateFieldName() start with the same letters. Something like "field_". This would result in something like "field_address" and "field_phone" etc).You would than just have to add the entry "field_*" (don't forget the wildcard!) to the $UdExcVarArray in pobs-ini.inc and the problems are over.

Inline HTML and <pre>
Programmers can use inline HTML in their PHP files. When POBS is instructed to concatenate codelines it normally is not a problem and doesn't compromise the HTML since carriage returns are not presented by return characters in HTML but by <br>. But, when <pre> is used before a piece of HTML code the browser interprets each return character as a <br>. Another problem with inline HTML is laid out in the paragraph below.

<pre>
This text will be displayed exactly as is seen here.
Every return in this text is interpreted as a carriage return by your browser.
</pre>

And this is what POBS can make of it:
<pre>
This text will be displayed exactly as is seen here.Every return in this text is interpreted as a carriage return by your browser.
</pre>

Javascript functions
Formerly I stated that when you were using inline Javascript you need to make adjustments. I was wrong. The only possible problem with inline Javascript I know of, is that you can't let POBS concatenate lines if you haven't ended each Javascript codeline with a semicolon ";". I guess this doesn't need extra explanation.

POBS does not (and can not easily) discriminate between JavaScript functions and PHP functions. It you declared a Javascript function named "X", POBS will replace this Javascript function and all references to it. As far as I know this will not create problems so there is no need to worry.

If you don't want your Javascript functions to be replaced, i.e. in case you want to debug it more easily, you can add them to $UdExcFuncArray in pobs-ini.inc or you can replace the inline Javascript with Javascript echoed by PHP. An example is shown below:

echo "function JsCheckField() {n";
echo "<Javascript code lines>n";
echo "}n";

This way POBS doesn' t consider "JsCheckField()" to be a function that needs replacement.

Extracting associative arrays
If you create an associative array and then extract() it, the extracted variables don't have encoded names. Here's an example.

Given an array such as:
$Va43fae1e=array('abpath'=>$Ve3f46e6e, 'unabpath'=>$V01031f9e);

This won't work:
extract($Va43fae1e);
because elsewhere you no longer have $abpath and $unabpath as variable names (they'd be obfuscated).

To deal with the problem you must add "abpath" and "unabpath" to $UdExcVarArray

Cookies
From version 0.93 on POBS deals properly with cookies and users can discard the cookie helptext presented here.

Cookies might cause problems since they are used in a normal fashion but defined and set in an unusual way.

setcookie ("TestCookie", "Test Value");
echo $TestCookie;

After POBS has done it's work the cookie "TestCookie" will still have be set but displaying the contents of the cookie will result in an empty string.

In the future POBS might just deal properly with this problem by also replacing setcookie("CookieName", "CookieValue") with setcookie("Veda45e23", "CookieValue"). But now it doesn't and here is what I suggest you to do.

Exclude all cookievariables by adding them to $UdExcVarArray in pobs-ini.inc. This is easiest done (and most secure) if you name every cookie according to a naming convention. Personally I start all cookienames with "whc_" so that I only have to add "whc_*" to the array. It's also good coding if you ask me. Scan your sourcefiles for the PHP function "setcookie" and give the first parameter a new name.

Walhalla Publicaties (c) 2001