btdsoft.com » OpenX Tips

Openx Market 500 error Fix for cpanel servers

Admin — Sun, 17 Jan 2010 16:55:14 +0000

Warning this information may be outdated. Please see the forum for up to date RevMax help and instructions. http://www.openxpayments.com.

At times when I install OpenX on a cpanel server, after log out, then back in, on a new installation, I will receive a error: 500 server error.

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

The infamous “500 internal server error” . The server leaving you with no real clues as to what actaully happened,

This is usually caused by permissions defined in
/openx/lib/OX/Plugin/PluginManager.php on line 52 .
Make sure they are defined correctly for your enviroment.

see more for helpful file permissions script.

In hopes of helping others on cpanel servers overcome this openxmarket 777 permissions issue, I took a moment to patch together the code below from snipplr.
If you have experienced the error, and are looking for answers, simply place the below file on your server within the /openx folder and call it in a browser. It will correctly set all folder and file permissions on a cpanle server with suphp. Related post.

Feel free to modify it to use on other files / folders where the permissions should be 755 for folders and 644 for files as needed. It will correctly set all sub directories and file permissions.

copy and paste to new file marketfix.php or other.


 error_reporting(E_ALL);
  require_once 'init.php';
 
     function oxMarketChmod($path, $filePerm=0644, $dirPerm=0755) {
      // Check if the path exists
      if(!file_exists($path))
      {
      return(FALSE);
      }
      // See whether this is a file
      if(is_file($path))
      {
      // Chmod the file with our given permissions
      chmod($path, $filePerm);
      // If this is a directory...
      }
 
      elseif(is_dir($path))
      {
      // Then get an array of the contents
      $foldersAndFiles = scandir($path);
      // Remove "." and ".." from the list
      $entries = array_slice($foldersAndFiles, 2);
      // Parse every result...
      foreach($entries as $entry)
      {
      // And call this function again recursively, with the same permissions
      oxMarketChmod($path."/".$entry, $filePerm, $dirPerm);
      }
      // When we are done with the contents of the directory, we chmod the directory itself
      chmod($path, $dirPerm);
      }
      // Everything seemed to work out well, return TRUE
      return(TRUE);
      }
     $plugins = oxMarketChmod(MAX_PATH.'/plugins/etc/oxMarket');
     $admin = oxMarketChmod(MAX_PATH.'/www/admin/plugins/oxMarket');
 
     if ($admin == $plugins){
     echo "All Done, you can login now";
     }
     else {
     echo 'Something has gone wrong... Perhaps oxMarket dosent exist?';
     }?>

File permission problems (UID:99)

Admin — Sat, 16 Jan 2010 02:07:29 +0000

Warning this information may be outdated. Please see the forum for up to date RevMax help and instructions. http://www.openxpayments.com.

It has come to my attention that some host seem a bit out dated and perhaps a bit unsecured as per files users and permissions. I am still researching it myself and looking for a solution that could possible fit all host. Until then if you encounter file permissions problems hopefully this will help.

Default installation php as mod_php module is one the biggest security hole at web servers software.
Lets consider why. If you have php installed as mod_php then all php applications are run under common user ‘nobody’ or ‘www’ or ‘apache’. It means if a user ‘smith’ has files located at his home directory, everyone else who has an account at the same server can read ( and modify ) his files using regular PHP-based filemanager.

To avoid this problem apache provides ‘suexec’ technology to run users’ software under their own system accounts. It means user ‘smith’ has ‘my_secure_data.txt’ chowned to ‘smith’ and it will work because his applications are run under ‘smith’ system account at suexec enviroment. Basically, suexec technology is provided for applications running as cgi scripts.

http://www.phpasks.com/suphp/

On Non-suphp server environment, if a php script has to upload a file on a folder, (eg: OpenX plugins) in order to get it uploaded to the folder, it needs to have world writable permissions (777).

As plugins are uploaded by php,On Non-suphp server environment it is usually assigned user id of 99. This will make any php uploaded files to not be owned by the ftp user and unable to change permissions, or delete them.

THE PROBLEM: For convenience RevMax sets all directory (755) and file (644) permissions on install and may cause errors. You must however manually set permissions for the clients folder /openx/clients, after uploading.

You can test your server for this issue. If you can use phpinfo() you can create a php file with the following contents:

 phpinfo(); ?>

Upload it to a web accessable folder on the server and browse to it in a browser, then look where it says Server API. If the value says Apache then its not running PHP using suPHP. If it says CGI then it is running suPHP.

If you know or can see this (uid:99) to be the issue, you can chown all the package folders and files, and chmod as needed. to restore functionality. Here’s some more info on “chown” and shell commands that may help.

If you know this before install you can uncompress the package and upload the files with ftp and set permissions accordingly, then log in to OpenX and install the plugin. You should then have ownership of all files and folders of the RevMax plugin. Plugin files and folders should be uploaded to the OpenX directory as seen in the unzipped package.

openx/clients….
openx/plugins/etc….
openx/www/admin/plugins…

To fix this problem permanently you may wish to follow this link and secure your server and install the suphp module for apache. This will of course make you go thru all of the plugins and reset file ownership and permissions as they are created on install with php and will cause errors as seen in openxmarket install on a cpanel server.

I am currently working on scripting to check for server variations, and hopefully fix this issue for these environments.

As always you can contact me directly or post to the forum if you have questions or need help.

OpenX Stats Problem

Admin — Mon, 13 Oct 2008 10:45:55 +0000

OpenX Delivery Security Update

I have been dealing with the stats being off for advertisers and publishers with a few clients for the last month. It seems the OpenX team has located the source of the problem and released a patch.

Blind SQL injection vulnerability

The problem seems to stem from a blind SQL injection vulnerability within the OpenX delivery engine, as described in OpenX security advisory OPENX-SA-2008-002. More Info.

Input passed to the “bannerid” parameter in www/delivery/ac.php is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

I have noted that all affected systems stats began to come more in line with actual adview and click through values, after applying the security patch.

Upgrading the OpenX delivery engine

Its a fairly simple and straight forward process of upgrading the openx delivery engine. You can download the patch from the OpenX website, and upload the files to your server. As always back up your files before you begin. You may also choose to upgrade your OpenX install to the latest non affected version. You can find the files and more information here.

Getting Help

If you do not feel comfortable upgrading OpenX or the delivery engine, as always my services are affordable and timely. Feel free to contact me for more information.

OpenX "INSERT_RANDOM_NUMBER_HERE"

Admin — Thu, 25 Sep 2008 19:05:42 +0000

Openx Invocation Tags Requiring Random Numbers

One of least understood and most often asked questions in regards to the OpenX banner invocation code must be the “INSERT_RANDOM_NUMBER_HERE” placed within the image, java and iframe invocation codes by OpenX.

This post will attempt to clarify this and give you some simple examples as to implementing on your site

Within the invocation code for a zone using the image, iframe, or javascript tag, there’s a part called “cb=INSERT_RANDOM_NUMBER_HERE”.

What is it ? Why is it needed ?

This is a unique number required to stop browser caching of your banners and ensures each end user will receive a new ad on page load. If we took the above example and simply inserted “cb=123″, the end user being a web browser or spider would eventually see this ad as a static non changing item and cache it. The user would then begin to see the same ad each time he accessed your page as its now stored in his browser cache with the stated id of 123.

If we generate a new number each time the ad is called, the browser, sees this as new content, and as such loads the new content on each visit.

Depending on your sites cms, design or other there are several language specific ways to generate this new random number on each page load. I will give a few examples below. Feel free to copy and paste as needed. Please perform test before implementing , or use at your own risk.

How to Generate A Random Number

php example:
First as its my personal favorite language I will provide an example in php.
This is the part that generates the number. If you are using more than 1 invocation tag on your site or within your template then place this code above your first banner call.

 $random_number = rand(1, 999999); ?>

Now we have a random number being generated each time the page is accessed. We can now place the random number within the OpenX banner invocation code.

Where you have “cb=INSERT_RANDOM_NUMBER_HERE”, simply replace as shown below

cb= echo"$random_number";?>

You now have a new unique id generated and inserted with php on each and every page load.

Java example:
Here’s an example for those with static html pages.

<script type='text/javascript'>
var randomnumber=Math.floor(Math.random()*99999999999);
document.write("+randomnumber);
document.write("'>");
script>

In order to implement the above code you will first need to generate a valid Image invocation tag from within OpenX to make sure that the domain and path to OpenX are valid, and that the < img > tag has the correct zoneid. So a valid invocation tag would look similar to below.

<script type='text/javascript'>