Plugin Tutorials 301 - Integrating With e107

Tutorial 301 - Rough notes - integrating with e107

Class2.php

Plug-ins must include class2.php in their main page(s), but not in other code (e.g. menus, plugin.php, etc.).

database

Many database actions are ready for use. The database server is already connected because the CMS is using it. The database name is as defined for e107 in the installation and that is what we are using for this tutorial. You will need to specify the table to use in your select statements.

This tutorial uses $tblname ='p_promo';

You should use The e107 database API for your database access rather than the standard PHP functions.

admin_config.php

Administrator pages (such as admin_config.php) need to be prefixed with admin_ in order to pick up the administrator theme. Alternatively, you can use $eplug_admin = TRUE; at the top of your code to load the administrator theme as well. This way you will not have to use the admin_ prefix.

Something on auth.php (Workaround on a problem)

The auth.php file should be included in most, if not all, administration pages. But as with much PHP programming, order of includes is important.

The auth.php file is responsible for performing a number of security checks, and then printing headers and the top of the HTML page. In most cases, your code should include other files (like languages and other libraries) before including auth.php. (And since these files are sent before the HTML headers, you should take care to program error handling accordingly.)

Example:

...
// This must be included first, since other libs depend upon it.
require_once("../../class2.php"); 

// Include your own scripts here!
require_once("language.inc.php"); // NB: include_lan() is probably better for this)

// Include page header stuff for administrator pages. INCLUDE OTHER STUFF BEFORE THIS!
require_once(e_ADMIN . "auth.php");

...

In the above example, the languages file is included before auth.php. Plug-in authors report that doing the includes in the reverse order (auth.php first, and language.inc.php second) might produce undesired results.

Writing safe plug-ins

Software is as strong as the weakest link.

Some plug-ins are vulnerable because hackers use their exploits. There are two basic rules for avoiding SQL-injections in your plugins:

1. Any (int) variables in SQL-queries which users/administrators send to you PHP script ($_POST, $_GET, $_COOKIES, e107 e_Query) must be used with intval().

Examples

• Very bad (!) - $sql->db_Select_gen("SELECT * FROM #user WHERE user_id=".$_POST['u']);
• Still bad (!!) - $sql->db_Select_gen("SELECT * FROM #user WHERE user_id='".$_POST['u']."'"); //bad only if magic_quotes_gpc=off - but this is not very rare situation
• Good - $sql->db_Select_gen("SELECT * FROM #user WHERE user_id=".intval($_POST['u']));

2. Any (varchar) variables in SQL queries which users/administrators send to you PHP script must be used with $tp->toDB().

Examples

• Bad (!) - $sql->db_Select_gen("SELECT * FROM #user WHERE user_name = '".$_GET['uname']."'");
• Good - $sql->db_Select_gen("SELECT * FROM #user WHERE user_name = '".$tp->toDB($_GET['uname'])."'");

This applies not only for "SELECT" queries, but also for "DELETE", "INSERT" and "UPDATE". If you will stick to these simple rules, there will be no danger for any SQL-injection at all!

What you need to know about PHP Security

With great power comes big responsibility. Please read this recommended PHP security tutorial on PHPfreaks.com.