Joomla! Documentation - User contributions [en]

Secure coding guidelines

2016-08-10T18:00:28Z

Globulopolis: Add info about json

Joomla includes many features that help with the task of securing applications and extensions built on it. You should always use these features if at all possible as they have been tried and tested by the many eyes of the developer community and any updates that might conceivably be required in the future will be automatically available whenever a Joomla update is applied. What follows is a description of best practice in using the Joomla API to ensure that your extensions are as secure as possible.

==Getting data from the request==
{{JVer|3.x}} Starting with Joomla version 3.0, [[Retrieving_request_data_using_JInput|JInput]] should be used instead of [[JRequest]].

All input originating from a user must be considered potentially dangerous and must be cleaned before being used. You should always use the Joomla [[Retrieving_request_data_using_JInput|JInput]] class to retrieve data from the request, rather than the raw $_GET, $_POST or $_REQUEST variables as the [[Retrieving_request_data_using_JInput|JInput]] methods apply input filtering by default. JInput deals with all aspects of the user request in a way that is independent of the request method used. It can also be used to retrieve cookie data and even server and environment variables. However, it is important to use the correct [[Retrieving_request_data_using_JInput|JInput]] method to ensure maximum security. It is very easy to just use the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] method with default parameters and ignore the fact that in many cases it is possible to apply a more stringent requirement on user input.

It very important to understand that the [[Retrieving_request_data_using_JInput|JInput]] methods are not SQL-aware and further work is required to guard against SQL injection attacks.There is no default value that will be returned if no default is specified in the call the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]]. If no default is specified and the argument is not present in the request variable then it will return undefined.

Using [[Retrieving_request_data_using_JInput|JInput]] also obviates the need to pay attention to the setting of magic_quotes_gpc. [[Retrieving_request_data_using_JInput|JInput]] does the right thing, regardless of whether magic_quotes_gpc is on or off. See http://php.net/manual/en/security.magicquotes.php for further information.

When considering user input you should think about the data type you are expecting to retrieve and apply the most stringent form of [[Retrieving_request_data_using_JInput#Getting_Values|JInput]] that is applicable in each case. In particular, avoid the lazy approach of using [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] as this will return an array that may contain entries that you did not expect and although each of those entries will have been cleaned, it is often the case that additional filtering could have been applied to some individual arguments. For example, the get method treats all arguments as strings, whereas it may be possible to restrict some arguments to be integers.

The first three parameters of each of the JInput get methods are the same. Only the first parameter is mandatory. In general, the format is
<source lang="php">
JFactory::getApplication->input-><data-source>->get<type>( <name>, <default> )
</source>
where

{| class="wikitable" border="1"
| <type> || the data type to be retrieved (see below for the types available).
|-
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value.
|-
| <data-source> || specifies where the variable is to be retrieved from (see below).
|}

The following values for <data-source> are supported:

{| class="wikitable" border="1"
| get || Data submitted in the query part of the URL.
|-
| post || Data submitted from form fields.
|-
| method || The same as either GET or POST depending on how the request was made.
|-
| cookie || Data submitted in cookies.
|-
| request || All the GET, POST and COOKIE data combined. This is the default.
|-
| files || Information about files uploaded as part of a POST request.
|-
| env || Environment variables (platform-specific).
|-
| server || Web server variables (platform-specific).
|}

Notice that the default is REQUEST, which includes cookie data.

The following sections look at each of the data types in more detail.

===Integer===
The following will accept an integer. An integer can include a leading minus sign, but a plus sign is not permitted.
<source lang="php">
$integer = JFactory::getApplication->input->getInt( 'id' );
</source>
will return the value of the "id" argument from the request (which by default includes all GET, POST and COOKIE data). The default value is zero.
<source lang="php">
$integer = JFactory::getApplication->input->cookie->getInt( 'myId', 12 );
</source>
will return the value of the "myId" variable from a cookie, with a default value of 12.

===Floating point number===
A floating point number can include a leading minus sign, but not a plus sign. If the number includes a decimal point, then there must be at least one digit before the decimal point. For example,
<source lang="php">
$float = JFactory::getApplication->input->getFloat( 'price' );
</source>
will return the value of the 'price' argument from the request. The default is "0.0".
<source lang="php">
$float = JFactory::getApplication->input->post->getFloat( 'total', 100.00 );
</source>
will retrieve the value of the 'total' argument from a POST request (but not a GET), with a default value of 100.00.

===Boolean value===
Any non-zero value is regarded as being true; zero is false.
<source lang="php">
$boolean = JFactory::getApplication->input->getBool( 'show' );
</source>
will return false if the value of the 'show' argument in the request is zero, or 1 (true) if the argument is anything else. The default is false. Note that any string argument will result in a return value of true, so calling the above with a URL containing "?show=false" will actually return true!
<source lang="php">
$boolean = JFactory::getApplication->input->get->getBool( 'hide', true );
</source>
will retrieve the value of the 'hide' argument from a GET request (but not a POST), with a default value of true.

===Word===
A word is defined as being a string of alphabetic characters. The underscore character is permitted as part of a word.
<source lang="php">
$word = JFactory::getApplication->input->cookie->getWord( 'search-word' );
</source>
will retrieve the value of the 'search-word' argument from the request. The default is an empty string.
<source lang="php">
$word = JFactory::getApplication->input->cookie->getWord( 'keyword', '' );
</source>
will retrieve the value of the 'keyword' variable from a cookie, with the default being an empty string.

===Command===
A command is like a word but a wider range of characters is permitted. Allowed characters are: all alphanumeric characters, dot, dash (hyphen) and underscore.
<source lang="php">
$command = JFactory::getApplication->input->getCmd( 'option' );
</source>
will retrieve the value of the "option" argument from the request. The default value is an empty string.
<source lang="php">
$command = JFactory::getApplication->input->post->getCmd( 'controller', 'view' );
</source>
will retrieve the value of the "controller" argument from a POST request (but not a GET), with a default value of 'view'.

===String===
The string type allows a much wider range of input characters. It also takes an optional fourth argument specifying some additional mask options. See [[#Filter options]] for information on the available masks.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'description' );
</source>
will retrieve the value of the "description" argument from the request. The default value is an empty string. The input will have whitespace removed from the left and right ends and any HTML tags will be removed.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'text', '' );
</source>
will retrieve the value of the "text" argument from the request.. The default value is an empty string.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'template', '<html />' );
</source>
will retrieve the value of the "template" argument from the request. The default value is '<html />'.

===JSON String===
<source lang="php">
$json = JFactory::getApplication->input->json->get( 'var_name' );
</source>

===Generic and other data types===
If the above methods do not meet your needs, there is a small number of additional filter types which you can use by calling the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] method directly. The syntax is:
<source lang="php">
JFactory::getApplication->input->get( <name>, <default>, <type> );
</source>
where:

{| class="wikitable" border="1"
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value. There is no default value that will be returned if no default is specified in the call the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]]. If no default is specified and the argument is not present in the request variable then it will return undefined.
|-
| <type> || specifies the data type expected (see below).
|}

The first three arguments are the same as for the more specific methods described earlier. Only the first argument is mandatory.

Allowed values of the <type>, which is case-insensitive, are as follows:

{| class="wikitable" border="1"
| INT, INTEGER || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getInt]].
|-
| UINT || Get an unsigned integer. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getUint]].
|-
| FLOAT, DOUBLE || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getFloat]].
|-
| BOOL, BOOLEAN || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getBool]].
|-
| WORD || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getWord]].
|-
| ALNUM || Allow only alphanumeric characters (a-z, A-Z, 0-9). Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getAlnum]].
|-
| CMD || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getCmd]].
|-
| BASE64 || Allow only those characters that could be present in a base64-encoded string (ie. a-z, A-Z, 0-9, /, + and =). Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getBase64]].
|-
| STRING || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getString]].
|-
| ARRAY || Source is not filtered but is cast to array type.
|-
| HTML || A sanitised string. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getHtml]].
|-
| PATH || Valid pathname regex that filters out common attacks. For example, any path beginning with a "/" will return an empty string. Simliarly, any path containing "/./" or "/../" will return an empty string. Dots within filenames are okay though. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getPath]].
|-
| USERNAME || Removes control characters (0x00 - 0x1F), 0x7F, <, >, ", ', % and &. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getUsername]].
|}

===Filter options===
All input values can be filtered using JFilterInput->clean.

Filter an array of values.
<source lang="php">
$data = JFactory::getApplication()->input->post->get('data', array(), 'array');
$filter = JFilterInput::getInstance();

foreach ($data as $value)
{
$array[] = $filter->clean($value, 'string');
}
</source>
For more filter types see [https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/filter/input.php#L115 JFilterInput source].

Options listed bellow available only in deprecated [[JRequest]] library.
Allowed values of <options> are as follows (none of these are applied by default):

{| class="wikitable" border="1"
| JREQUEST_NOTRIM || Does not remove whitespace from the start and ends of strings.
|-
| JREQUEST_ALLOWRAW || Does not do any filtering at all. Use with extreme caution.
|-
| JREQUEST_ALLOWHTML || Does not remove HTML from string inputs.
|}

Masks can be combined by logically OR'ing them. If no filter options are specified, then by default, whitespace is trimmed and HTML is removed.

===File uploads===
Web servers already have a good deal of security around handling file uploads, but it is still necessary to take additional steps to ensure that file names and paths cannot be abused. A simplified form which requests a file to be uploaded looks like this:
<source lang="html4strict">
<form action="index.php?option=com_mycomponent/form_handler.php" method="post" enctype="multipart/form-data">
<input type="file" name="Filedata" />
<input type="submit" />
</form>
</source>
On clicking the submit button, the browser will upload the file in a POST request, passing control to Joomla which will call "components/com_mycomponent/form_handler.php". This will include code like the following. The variable $somepath must be set to some path where the web server has permission to create files.
<source lang="php">
// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die( 'Restricted access' );

// Get the file data array from the request.
$file = JFactory::getApplication->input->get( 'Filedata', '', 'files', 'array' );

// Make the file name safe.
jimport('joomla.filesystem.file');
$file['name'] = JFile::makeSafe($file['name']);

// Move the uploaded file into a permanent location.
if (isset( $file['name'] )) {

// Make sure that the full file path is safe.
$filepath = JPath::clean( $somepath.'/'.strtolower( $file['name'] ) );

// Move the uploaded file.
JFile::upload( $file['tmp_name'], $filepath );
}
</source>

===Saving a request variable into user state===
Because setting a user state variable from a variable in the request is such a common operation, there is an API method to make the task easier. This is generally safe to use because it calls [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] to obtain the input from the request, but remember that none of the input filtering calls will protect against SQL injection attempts.
<source lang="php">
$app = JFactory::getApplication();
$app->getUserStateFromRequest( <key>, <name>, <default>, <type> );
</source>
where
{| class="wikitable" border="1"
| <key> || the name of the variable in the user state.
|-
| <name> || the name of the request variable (same as the first argument of a [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] call).
|-
| <default> || the default value to be assigned to the user state variable if the request variable is absent. The default is null.
|-
| <type> || the type of variable expected.
|}

For example, getting an integer variable called 'id' from the request with a default value of 0, then saving it into a session variable called 'myid' can be done like this:
<source lang="php">
$app = JFactory::getApplication();
$app->getUserStateFromRequest( 'myid', 'id, 0, 'int' );
</source>
instead of something like this:
<source lang="php">
$app = JFactory::getApplication();
$app->setUserState( 'myid', $app->input->getInt( 'id', 0 ) );
</source>

==Constructing SQL queries==
One of the most common forms of attack on web applications is SQL injection, where the aim of the attacker is to change a database query by exploiting a poorly filtered input variable. Injecting modified SQL statements into the database can damage data or reveal private information. It is important to ensure that when SQL statements are constructed, they are correctly escaped and quoted so that bad input data cannot result in a bad SQL statement. You cannot rely on the [[Retrieving_request_data_using_JInput|JInput]] methods to do this as they are not SQL-aware.

===Secure integers and the rest of numeric values===
With the MySQL database, numeric fields should not be quoted, so it is important that they be typecast instead. Failure to do this will leave your code vulnerable to an attacker inserting a string containing SQL data.

Depending on the type, numeric types are cast like this:
<source lang="php">
// For SQL data types: INT, INTEGER, TINYINT, SMALLINT, MEDIUMINT, BIGINT, YEAR
$query = 'SELECT * FROM #__table WHERE `id`=' . (int) $id;

// For SQL data types: FLOAT, DOUBLE
$query = 'SELECT * FROM #__table WHERE `id`=' . (float) $id;
</source>
It's a good idea to get into the habit of always typecasting integers like this even if the variable was previously obtained using [[Further information on SQL injection attacks can be found here: http://php.net/manual/en/security.database.sql-injection.php and here: [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getInt]].

===Secure strings===
In the examples that follow it is assumed that $db is an instance of a Joomla database object. This can always be obtained from [[JFactory]] using
<source lang="php">
$db = JFactory::getDBO();
</source>
Strings should always be escaped before being used in an SQL statement. This is actually very simple as the [[JDatabase/quote|JDatabase->quote]] method escapes everything for you. You can also use the [[JDatabase/escape|JDatabase->escape]] method directly. The following statements are equivalent:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $db->escape( $field ), false );

$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $field );
</source>
===Secure on search===
Special attention should be paid to LIKE clauses which contain the % wildcard character as these require special escaping in order to avoid possible denial of service attacks. LIKE clauses can be handled like this:
<source lang="php">
// Construct the search term by escaping the user-supplied string and, if required, adding the % wildcard characters manually.
$search = '%' . $db->escape( $search, true ) . '%' );

// Construct the SQL query, being careful to suppress the default behaviour of Quote so as to prevent double-escaping.
$query = 'SELECT * FROM #__table WHERE `field` LIKE ' . $db->quote( $search, false );
</source>

===Secure dates===
If data is to be entered into a datetime column then you can use the Joomla API to ensure a valid date format:
<source lang="php">
$date = JFactory::getDate( $mydate );
$query = 'UPDATE #__table SET `date` = ' . $db->quote( $date->toMySQL(), false );
</source>
Note that it is necessary to suppress database escaping as legitimate dates may contain characters that should not be escaped.

===Secure field names===
In the comparatively rare case where a field name is a variable, that should also be quoted using an API call:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE ' . $db->quoteName( $field-name ) . '=' . $db->quote( $field-value );
</source>

===Secure arrays of integers===
When you have an array of ids, typically used for IN() queries, you have to sanitise it also with JArrayHelper::toInteger($cid); before imploding:

<source lang="php">
...
JArrayHelper::toInteger($catId);
$query->where($db->quoteName('x.category_id') . ' IN (' . implode(',', $catId) . ')');
</source>

===Short aliases of Quote and QuoteName===
Shorter alternatives to the quote methods may also be used. The following statements are equivalent:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE ' . $db->quoteName( $field-name ) . '=' . $db->quote( $field-value );
$query = 'SELECT * FROM #__table WHERE ' . $db->qn( $field-name ) . '=' . $db->q( $field-value );
</source>

==Securing forms==
Apart from cleaning input variables as described above, you can also implement a simple technique which makes it more difficult for a cross-site request forgery attack (CSRF) to succeed. This involves adding a randomly-generated unique token to the form which is checked against a copy of the token held in the user's session. By checking that the submitted token matches the one contained in the stored session, it is possible to tie a rendered form to the request variables presented.

In POST forms you should add a hidden token field using:
<source lang="php">
echo JHTML::_( 'form.token' );
</source>
This outputs the token as a hidden form field looking like this:
<source lang="html4strict">
<input type="hidden" name="8cb24ae69ffd7828ccecbcf06056e6fc" value="1" />
</source>
and places a copy of the token into the user's session, for later checking.

If you need to add the token to a URL rather than a form then you can use something like this:
<source lang="php">
echo JRoute::_( 'index.php?option=com_mycomponent&' . JSession::getFormToken() . '=1' );
</source>

In the most common scenario, you will want to check the token following a POST to the form handler. This can be done by adding this line of code to form handler:
<source lang="php">
JSession::checkToken() or die( JText::_( 'Invalid Token' ) );
</source>
If you need to pass the token in a GET request then you can check it like this:
<source lang="php">
JSession::checkToken( 'get' ) or die( JText::_( 'Invalid Token' ) );
</source>

In both cases the code will die if the token is omitted from the request, or the submitted token does not match the session token. If the token is correct but has expired, then [[JSession/checkToken|JSession::checkToken]] will automatically redirect to the site front page.

==Cleaning filesystem paths==
If there is any possibility that a filesystem path might be constructed using data that originated from user input, then the path must be cleaned and checked before being used. This can be done quite simply like this:
<source lang="php">
JPath::check( $path );
</source>
This will raise an error and terminate Joomla if the path contains a ".." or leads to a location outside the Joomla root directory. If you want to deal with the error yourself without terminating the application, then you can use code like this:
<source lang="php">
$path = JPath::clean( $path );
if (strpos( $path, JPath::clean( JPATH_ROOT ) ) !== 0) {
// Handle the error here.
}
</source>
The [[JPath:clean]] method can be used in your own code too. It merely removes leading and trailing whitespace and replace double slashes and backslashes with the standard directory separator.

==Cleaning filesystem file names==
As with filesystem paths, if there is any possibility that a file name might be constructed using user-originated data, then the file name must be cleaned and checked before use. This can be done like this:
<source lang="php">
jimport('joomla.filesystem.file');
$clean = JFile::makeSafe( $unclean );
</source>
This method removes sequences of two or more "." characters and any character that is not alphabetic, numeric or a dot, dash or underscore character. If there is a leading dot then that is removed too.
[[Category:Development]][[Category:Security]]

Retrieving request data using JInput

2016-08-10T17:50:33Z

Globulopolis:

Secure coding guidelines

2016-05-19T15:02:07Z

Globulopolis: Update information about filter options.

Joomla includes many features that help with the task of securing applications and extensions built on it. You should always use these features if at all possible as they have been tried and tested by the many eyes of the developer community and any updates that might conceivably be required in the future will be automatically available whenever a Joomla update is applied. What follows is a description of best practice in using the Joomla API to ensure that your extensions are as secure as possible.

==Getting data from the request==
{{JVer|3.x}} Starting with Joomla version 3.0, [[Retrieving_request_data_using_JInput|JInput]] should be used instead of [[JRequest]].

All input originating from a user must be considered potentially dangerous and must be cleaned before being used. You should always use the Joomla [[Retrieving_request_data_using_JInput|JInput]] class to retrieve data from the request, rather than the raw $_GET, $_POST or $_REQUEST variables as the [[Retrieving_request_data_using_JInput|JInput]] methods apply input filtering by default. JInput deals with all aspects of the user request in a way that is independent of the request method used. It can also be used to retrieve cookie data and even server and environment variables. However, it is important to use the correct [[Retrieving_request_data_using_JInput|JInput]] method to ensure maximum security. It is very easy to just use the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] method with default parameters and ignore the fact that in many cases it is possible to apply a more stringent requirement on user input.

It very important to understand that the [[Retrieving_request_data_using_JInput|JInput]] methods are not SQL-aware and further work is required to guard against SQL injection attacks.There is no default value that will be returned if no default is specified in the call the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]]. If no default is specified and the argument is not present in the request variable then it will return undefined.

Using [[Retrieving_request_data_using_JInput|JInput]] also obviates the need to pay attention to the setting of magic_quotes_gpc. [[Retrieving_request_data_using_JInput|JInput]] does the right thing, regardless of whether magic_quotes_gpc is on or off. See http://php.net/manual/en/security.magicquotes.php for further information.

When considering user input you should think about the data type you are expecting to retrieve and apply the most stringent form of [[Retrieving_request_data_using_JInput#Getting_Values|JInput]] that is applicable in each case. In particular, avoid the lazy approach of using [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] as this will return an array that may contain entries that you did not expect and although each of those entries will have been cleaned, it is often the case that additional filtering could have been applied to some individual arguments. For example, the get method treats all arguments as strings, whereas it may be possible to restrict some arguments to be integers.

The first three parameters of each of the JInput get methods are the same. Only the first parameter is mandatory. In general, the format is
<source lang="php">
JFactory::getApplication->input-><data-source>->get<type>( <name>, <default> )
</source>
where

{| class="wikitable" border="1"
| <type> || the data type to be retrieved (see below for the types available).
|-
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value.
|-
| <data-source> || specifies where the variable is to be retrieved from (see below).
|}

The following values for <data-source> are supported:

{| class="wikitable" border="1"
| get || Data submitted in the query part of the URL.
|-
| post || Data submitted from form fields.
|-
| method || The same as either GET or POST depending on how the request was made.
|-
| cookie || Data submitted in cookies.
|-
| request || All the GET, POST and COOKIE data combined. This is the default.
|-
| files || Information about files uploaded as part of a POST request.
|-
| env || Environment variables (platform-specific).
|-
| server || Web server variables (platform-specific).
|}

Notice that the default is REQUEST, which includes cookie data.

The following sections look at each of the data types in more detail.

===Integer===
The following will accept an integer. An integer can include a leading minus sign, but a plus sign is not permitted.
<source lang="php">
$integer = JFactory::getApplication->input->getInt( 'id' );
</source>
will return the value of the "id" argument from the request (which by default includes all GET, POST and COOKIE data). The default value is zero.
<source lang="php">
$integer = JFactory::getApplication->input->cookie->getInt( 'myId', 12 );
</source>
will return the value of the "myId" variable from a cookie, with a default value of 12.

===Floating point number===
A floating point number can include a leading minus sign, but not a plus sign. If the number includes a decimal point, then there must be at least one digit before the decimal point. For example,
<source lang="php">
$float = JFactory::getApplication->input->getFloat( 'price' );
</source>
will return the value of the 'price' argument from the request. The default is "0.0".
<source lang="php">
$float = JFactory::getApplication->input->post->getFloat( 'total', 100.00 );
</source>
will retrieve the value of the 'total' argument from a POST request (but not a GET), with a default value of 100.00.

===Boolean value===
Any non-zero value is regarded as being true; zero is false.
<source lang="php">
$boolean = JFactory::getApplication->input->getBool( 'show' );
</source>
will return false if the value of the 'show' argument in the request is zero, or 1 (true) if the argument is anything else. The default is false. Note that any string argument will result in a return value of true, so calling the above with a URL containing "?show=false" will actually return true!
<source lang="php">
$boolean = JFactory::getApplication->input->get->getBool( 'hide', true );
</source>
will retrieve the value of the 'hide' argument from a GET request (but not a POST), with a default value of true.

===Word===
A word is defined as being a string of alphabetic characters. The underscore character is permitted as part of a word.
<source lang="php">
$word = JFactory::getApplication->input->cookie->getWord( 'search-word' );
</source>
will retrieve the value of the 'search-word' argument from the request. The default is an empty string.
<source lang="php">
$word = JFactory::getApplication->input->cookie->getWord( 'keyword', '' );
</source>
will retrieve the value of the 'keyword' variable from a cookie, with the default being an empty string.

===Command===
A command is like a word but a wider range of characters is permitted. Allowed characters are: all alphanumeric characters, dot, dash (hyphen) and underscore.
<source lang="php">
$command = JFactory::getApplication->input->getCmd( 'option' );
</source>
will retrieve the value of the "option" argument from the request. The default value is an empty string.
<source lang="php">
$command = JFactory::getApplication->input->post->getCmd( 'controller', 'view' );
</source>
will retrieve the value of the "controller" argument from a POST request (but not a GET), with a default value of 'view'.

===String===
The string type allows a much wider range of input characters. It also takes an optional fourth argument specifying some additional mask options. See [[#Filter options]] for information on the available masks.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'description' );
</source>
will retrieve the value of the "description" argument from the request. The default value is an empty string. The input will have whitespace removed from the left and right ends and any HTML tags will be removed.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'text', '' );
</source>
will retrieve the value of the "text" argument from the request.. The default value is an empty string.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'template', '<html />' );
</source>
will retrieve the value of the "template" argument from the request. The default value is '<html />'.

===Generic and other data types===
If the above methods do not meet your needs, there is a small number of additional filter types which you can use by calling the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] method directly. The syntax is:
<source lang="php">
JFactory::getApplication->input->get( <name>, <default>, <type> );
</source>
where:

{| class="wikitable" border="1"
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value. There is no default value that will be returned if no default is specified in the call the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]]. If no default is specified and the argument is not present in the request variable then it will return undefined.
|-
| <type> || specifies the data type expected (see below).
|}

The first three arguments are the same as for the more specific methods described earlier. Only the first argument is mandatory.

Allowed values of the <type>, which is case-insensitive, are as follows:

{| class="wikitable" border="1"
| INT, INTEGER || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getInt]].
|-
| UINT || Get an unsigned integer. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getUint]].
|-
| FLOAT, DOUBLE || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getFloat]].
|-
| BOOL, BOOLEAN || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getBool]].
|-
| WORD || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getWord]].
|-
| ALNUM || Allow only alphanumeric characters (a-z, A-Z, 0-9). Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getAlnum]].
|-
| CMD || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getCmd]].
|-
| BASE64 || Allow only those characters that could be present in a base64-encoded string (ie. a-z, A-Z, 0-9, /, + and =). Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getBase64]].
|-
| STRING || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getString]].
|-
| ARRAY || Source is not filtered but is cast to array type.
|-
| HTML || A sanitised string. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getHtml]].
|-
| PATH || Valid pathname regex that filters out common attacks. For example, any path beginning with a "/" will return an empty string. Simliarly, any path containing "/./" or "/../" will return an empty string. Dots within filenames are okay though. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getPath]].
|-
| USERNAME || Removes control characters (0x00 - 0x1F), 0x7F, <, >, ", ', % and &. Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getUsername]].
|}

===Filter options===
All input values can be filtered using JFilterInput->clean.

Filter an array of values.
<source lang="php">
$data = JFactory::getApplication()->input->post->get('data', array(), 'array');
$filter = JFilterInput::getInstance();

foreach ($data as $value)
{
$array[] = $filter->clean($value, 'string');
}
</source>
For more filter types see [https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/filter/input.php#L115 JFilterInput source].

Options listed bellow available only in deprecated [[JRequest]] library.
Allowed values of <options> are as follows (none of these are applied by default):

{| class="wikitable" border="1"
| JREQUEST_NOTRIM || Does not remove whitespace from the start and ends of strings.
|-
| JREQUEST_ALLOWRAW || Does not do any filtering at all. Use with extreme caution.
|-
| JREQUEST_ALLOWHTML || Does not remove HTML from string inputs.
|}

Masks can be combined by logically OR'ing them. If no filter options are specified, then by default, whitespace is trimmed and HTML is removed.

===File uploads===
Web servers already have a good deal of security around handling file uploads, but it is still necessary to take additional steps to ensure that file names and paths cannot be abused. A simplified form which requests a file to be uploaded looks like this:
<source lang="html4strict">
<form action="index.php?option=com_mycomponent/form_handler.php" method="post" enctype="multipart/form-data">
<input type="file" name="Filedata" />
<input type="submit" />
</form>
</source>
On clicking the submit button, the browser will upload the file in a POST request, passing control to Joomla which will call "components/com_mycomponent/form_handler.php". This will include code like the following. The variable $somepath must be set to some path where the web server has permission to create files.
<source lang="php">
// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die( 'Restricted access' );

// Get the file data array from the request.
$file = JFactory::getApplication->input->get( 'Filedata', '', 'files', 'array' );

// Make the file name safe.
jimport('joomla.filesystem.file');
$file['name'] = JFile::makeSafe($file['name']);

// Move the uploaded file into a permanent location.
if (isset( $file['name'] )) {

// Make sure that the full file path is safe.
$filepath = JPath::clean( $somepath.'/'.strtolower( $file['name'] ) );

// Move the uploaded file.
JFile::upload( $file['tmp_name'], $filepath );
}
</source>

===Saving a request variable into user state===
Because setting a user state variable from a variable in the request is such a common operation, there is an API method to make the task easier. This is generally safe to use because it calls [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] to obtain the input from the request, but remember that none of the input filtering calls will protect against SQL injection attempts.
<source lang="php">
$app = JFactory::getApplication();
$app->getUserStateFromRequest( <key>, <name>, <default>, <type> );
</source>
where
{| class="wikitable" border="1"
| <key> || the name of the variable in the user state.
|-
| <name> || the name of the request variable (same as the first argument of a [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] call).
|-
| <default> || the default value to be assigned to the user state variable if the request variable is absent. The default is null.
|-
| <type> || the type of variable expected.
|}

For example, getting an integer variable called 'id' from the request with a default value of 0, then saving it into a session variable called 'myid' can be done like this:
<source lang="php">
$app = JFactory::getApplication();
$app->getUserStateFromRequest( 'myid', 'id, 0, 'int' );
</source>
instead of something like this:
<source lang="php">
$app = JFactory::getApplication();
$app->setUserState( 'myid', $app->input->getInt( 'id', 0 ) );
</source>

==Constructing SQL queries==
One of the most common forms of attack on web applications is SQL injection, where the aim of the attacker is to change a database query by exploiting a poorly filtered input variable. Injecting modified SQL statements into the database can damage data or reveal private information. It is important to ensure that when SQL statements are constructed, they are correctly escaped and quoted so that bad input data cannot result in a bad SQL statement. You cannot rely on the [[Retrieving_request_data_using_JInput|JInput]] methods to do this as they are not SQL-aware.

===Secure integers and the rest of numeric values===
With the MySQL database, numeric fields should not be quoted, so it is important that they be typecast instead. Failure to do this will leave your code vulnerable to an attacker inserting a string containing SQL data.

Depending on the type, numeric types are cast like this:
<source lang="php">
// For SQL data types: INT, INTEGER, TINYINT, SMALLINT, MEDIUMINT, BIGINT, YEAR
$query = 'SELECT * FROM #__table WHERE `id`=' . (int) $id;

// For SQL data types: FLOAT, DOUBLE
$query = 'SELECT * FROM #__table WHERE `id`=' . (float) $id;
</source>
It's a good idea to get into the habit of always typecasting integers like this even if the variable was previously obtained using [[Further information on SQL injection attacks can be found here: http://php.net/manual/en/security.database.sql-injection.php and here: [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getInt]].

===Secure strings===
In the examples that follow it is assumed that $db is an instance of a Joomla database object. This can always be obtained from [[JFactory]] using
<source lang="php">
$db = JFactory::getDBO();
</source>
Strings should always be escaped before being used in an SQL statement. This is actually very simple as the [[JDatabase/quote|JDatabase->quote]] method escapes everything for you. You can also use the [[JDatabase/escape|JDatabase->escape]] method directly. The following statements are equivalent:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $db->escape( $field ), false );

$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $field );
</source>
===Secure on search===
Special attention should be paid to LIKE clauses which contain the % wildcard character as these require special escaping in order to avoid possible denial of service attacks. LIKE clauses can be handled like this:
<source lang="php">
// Construct the search term by escaping the user-supplied string and, if required, adding the % wildcard characters manually.
$search = '%' . $db->escape( $search, true ) . '%' );

// Construct the SQL query, being careful to suppress the default behaviour of Quote so as to prevent double-escaping.
$query = 'SELECT * FROM #__table WHERE `field` LIKE ' . $db->quote( $search, false );
</source>

===Secure dates===
If data is to be entered into a datetime column then you can use the Joomla API to ensure a valid date format:
<source lang="php">
$date = JFactory::getDate( $mydate );
$query = 'UPDATE #__table SET `date` = ' . $db->quote( $date->toMySQL(), false );
</source>
Note that it is necessary to suppress database escaping as legitimate dates may contain characters that should not be escaped.

===Secure field names===
In the comparatively rare case where a field name is a variable, that should also be quoted using an API call:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE ' . $db->quoteName( $field-name ) . '=' . $db->quote( $field-value );
</source>

===Secure arrays of integers===
When you have an array of ids, typically used for IN() queries, you have to sanitise it also with JArrayHelper::toInteger($cid); before imploding:

<source lang="php">
...
JArrayHelper::toInteger($catId);
$query->where($db->quoteName('x.category_id') . ' IN (' . implode(',', $catId) . ')');
</source>

===Short aliases of Quote and QuoteName===
Shorter alternatives to the quote methods may also be used. The following statements are equivalent:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE ' . $db->quoteName( $field-name ) . '=' . $db->quote( $field-value );
$query = 'SELECT * FROM #__table WHERE ' . $db->qn( $field-name ) . '=' . $db->q( $field-value );
</source>

==Securing forms==
Apart from cleaning input variables as described above, you can also implement a simple technique which makes it more difficult for a cross-site request forgery attack (CSRF) to succeed. This involves adding a randomly-generated unique token to the form which is checked against a copy of the token held in the user's session. By checking that the submitted token matches the one contained in the stored session, it is possible to tie a rendered form to the request variables presented.

In POST forms you should add a hidden token field using:
<source lang="php">
echo JHTML::_( 'form.token' );
</source>
This outputs the token as a hidden form field looking like this:
<source lang="html4strict">
<input type="hidden" name="8cb24ae69ffd7828ccecbcf06056e6fc" value="1" />
</source>
and places a copy of the token into the user's session, for later checking.

If you need to add the token to a URL rather than a form then you can use something like this:
<source lang="php">
echo JRoute::_( 'index.php?option=com_mycomponent&' . JSession::getFormToken() . '=1' );
</source>

In the most common scenario, you will want to check the token following a POST to the form handler. This can be done by adding this line of code to form handler:
<source lang="php">
JSession::checkToken() or die( JText::_( 'Invalid Token' ) );
</source>
If you need to pass the token in a GET request then you can check it like this:
<source lang="php">
JSession::checkToken( 'get' ) or die( JText::_( 'Invalid Token' ) );
</source>

In both cases the code will die if the token is omitted from the request, or the submitted token does not match the session token. If the token is correct but has expired, then [[JSession/checkToken|JSession::checkToken]] will automatically redirect to the site front page.

==Cleaning filesystem paths==
If there is any possibility that a filesystem path might be constructed using data that originated from user input, then the path must be cleaned and checked before being used. This can be done quite simply like this:
<source lang="php">
JPath::check( $path );
</source>
This will raise an error and terminate Joomla if the path contains a ".." or leads to a location outside the Joomla root directory. If you want to deal with the error yourself without terminating the application, then you can use code like this:
<source lang="php">
$path = JPath::clean( $path );
if (strpos( $path, JPath::clean( JPATH_ROOT ) ) !== 0) {
// Handle the error here.
}
</source>
The [[JPath:clean]] method can be used in your own code too. It merely removes leading and trailing whitespace and replace double slashes and backslashes with the standard directory separator.

==Cleaning filesystem file names==
As with filesystem paths, if there is any possibility that a file name might be constructed using user-originated data, then the file name must be cleaned and checked before use. This can be done like this:
<source lang="php">
jimport('joomla.filesystem.file');
$clean = JFile::makeSafe( $unclean );
</source>
This method removes sequences of two or more "." characters and any character that is not alphabetic, numeric or a dot, dash or underscore character. If there is a leading dot then that is removed too.
[[Category:Development]][[Category:Security]]

Secure coding guidelines

2016-02-15T20:39:44Z

Globulopolis: Remove deprecated JRequest and update to actual JInput and JSession.

{{page|needs technical review|This page uses out of date standards e.g. JRequest}}
Joomla includes many features that help with the task of securing applications and extensions built on it. You should always use these features if at all possible as they have been tried and tested by the many eyes of the developer community and any updates that might conceivably be required in the future will be automatically available whenever a Joomla update is applied. What follows is a description of best practice in using the Joomla API to ensure that your extensions are as secure as possible.

==Getting data from the request==
{{JVer|3.x}} Starting with Joomla version 3.0, [[Retrieving_request_data_using_JInput|JInput]] should be used instead of [[JRequest]].

All input originating from a user must be considered potentially dangerous and must be cleaned before being used. You should always use the Joomla [[Retrieving_request_data_using_JInput|JInput]] class to retrieve data from the request, rather than the raw $_GET, $_POST or $_REQUEST variables as the [[Retrieving_request_data_using_JInput|JInput]] methods apply input filtering by default. JInput deals with all aspects of the user request in a way that is independent of the request method used. It can also be used to retrieve cookie data and even server and environment variables. However, it is important to use the correct [[Retrieving_request_data_using_JInput|JInput]] method to ensure maximum security. It is very easy to just use the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] method with default parameters and ignore the fact that in many cases it is possible to apply a more stringent requirement on user input.

It very important to understand that the [[Retrieving_request_data_using_JInput|JInput]] methods are not SQL-aware and further work is required to guard against SQL injection attacks.There is no default value that will be returned if no default is specified in the call the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]]. If no default is specified and the argument is not present in the request variable then it will return undefined.

Using [[Retrieving_request_data_using_JInput|JInput]] also obviates the need to pay attention to the setting of magic_quotes_gpc. [[Retrieving_request_data_using_JInput|JInput]] does the right thing, regardless of whether magic_quotes_gpc is on or off. See http://php.net/manual/en/security.magicquotes.php for further information.

When considering user input you should think about the data type you are expecting to retrieve and apply the most stringent form of [[Retrieving_request_data_using_JInput#Getting_Values|JInput]] that is applicable in each case. In particular, avoid the lazy approach of using [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] as this will return an array that may contain entries that you did not expect and although each of those entries will have been cleaned, it is often the case that additional filtering could have been applied to some individual arguments. For example, the get method treats all arguments as strings, whereas it may be possible to restrict some arguments to be integers.

The first three parameters of each of the JInput get methods are the same. Only the first parameter is mandatory. In general, the format is
<source lang="php">
JFactory::getApplication->input-><data-source>->get<type>( <name>, <default>, <filter> )
</source>
where

{| class="wikitable" border="1"
| <type> || the data type to be retrieved (see below for the types available).
|-
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value.
|-
| <data-source> || specifies where the variable is to be retrieved from (see below).
|-
| <filter> || specifies how JInput should filter variable value. See [[JFilterInput|JFilterInput->clean]]
|}

The following values for <data-source> are supported:

{| class="wikitable" border="1"
| get || Data submitted in the query part of the URL.
|-
| post || Data submitted from form fields.
|-
| method || The same as either GET or POST depending on how the request was made.
|-
| cookie || Data submitted in cookies.
|-
| request || All the GET, POST and COOKIE data combined. This is the default.
|-
| files || Information about files uploaded as part of a POST request.
|-
| env || Environment variables (platform-specific).
|-
| server || Web server variables (platform-specific).
|}

Notice that the default is REQUEST, which includes cookie data.

The following sections look at each of the data types in more detail.

===Integer===
The following will accept an integer. An integer can include a leading minus sign, but a plus sign is not permitted.
<source lang="php">
$integer = JFactory::getApplication->input->getInt( 'id' );
</source>
will return the value of the "id" argument from the request (which by default includes all GET, POST and COOKIE data). The default value is zero.
<source lang="php">
$integer = JFactory::getApplication->input->cookie->getInt( 'myId', 12 );
</source>
will return the value of the "myId" variable from a cookie, with a default value of 12.

===Floating point number===
A floating point number can include a leading minus sign, but not a plus sign. If the number includes a decimal point, then there must be at least one digit before the decimal point. For example,
<source lang="php">
$float = JFactory::getApplication->input->getFloat( 'price' );
</source>
will return the value of the 'price' argument from the request. The default is "0.0".
<source lang="php">
$float = JFactory::getApplication->input->post->getFloat( 'total', 100.00 );
</source>
will retrieve the value of the 'total' argument from a POST request (but not a GET), with a default value of 100.00.

===Boolean value===
Any non-zero value is regarded as being true; zero is false.
<source lang="php">
$boolean = JFactory::getApplication->input->getBool( 'show' );
</source>
will return false if the value of the 'show' argument in the request is zero, or 1 (true) if the argument is anything else. The default is false. Note that any string argument will result in a return value of true, so calling the above with a URL containing "?show=false" will actually return true!
<source lang="php">
$boolean = JFactory::getApplication->input->get->getBool( 'hide', true );
</source>
will retrieve the value of the 'hide' argument from a GET request (but not a POST), with a default value of true.

===Word===
A word is defined as being a string of alphabetic characters. The underscore character is permitted as part of a word.
<source lang="php">
$word = JFactory::getApplication->input->cookie->getWord( 'search-word' );
</source>
will retrieve the value of the 'search-word' argument from the request. The default is an empty string.
<source lang="php">
$word = JFactory::getApplication->input->cookie->getWord( 'keyword', '' );
</source>
will retrieve the value of the 'keyword' variable from a cookie, with the default being an empty string.

===Command===
A command is like a word but a wider range of characters is permitted. Allowed characters are: all alphanumeric characters, dot, dash (hyphen) and underscore.
<source lang="php">
$command = JFactory::getApplication->input->getCmd( 'option' );
</source>
will retrieve the value of the "option" argument from the request. The default value is an empty string.
<source lang="php">
$command = JFactory::getApplication->input->post->getCmd( 'controller', 'view' );
</source>
will retrieve the value of the "controller" argument from a POST request (but not a GET), with a default value of 'view'.

===String===
The string type allows a much wider range of input characters. It also takes an optional fourth argument specifying some additional mask options. See [[#Filter options]] for information on the available masks.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'description' );
</source>
will retrieve the value of the "description" argument from the request. The default value is an empty string. The input will have whitespace removed from the left and right ends and any HTML tags will be removed.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'text', '' );
</source>
will retrieve the value of the "text" argument from the request.. The default value is an empty string.
<source lang="php">
$string = JFactory::getApplication->input->getString( 'template', '<html />' );
</source>
will retrieve the value of the "template" argument from the request. The default value is '<html />'.

===Generic and other data types===
If the above methods do not meet your needs, there is a small number of additional filter types which you can use by calling the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] method directly. The syntax is:
<source lang="php">
JFactory::getApplication->input->get( <name>, <default>, <type> );
</source>
where:

{| class="wikitable" border="1"
| <name> || the name of the variable to be retrieved (for example, the name of an argument in a URL).
|-
| <default> || the default value. There is no default value that will be returned if no default is specified in the call the [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]]. If no default is specified and the argument is not present in the request variable then it will return undefined.
|-
| <type> || specifies the data type expected (see below).
|}

The first three arguments are the same as for the more specific methods described earlier. Only the first argument is mandatory.

Allowed values of the <type>, which is case-insensitive, are as follows:

{| class="wikitable" border="1"
| INT, INTEGER || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getInt]].
|-
| FLOAT, DOUBLE || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getFloat]].
|-
| BOOL, BOOLEAN || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getBool]].
|-
| WORD || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getWord]].
|-
| ALNUM || Allow only alphanumeric characters (a-z, A-Z, 0-9).
|-
| CMD || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getCmd]].
|-
| BASE64 || Allow only those characters that could be present in a base64-encoded string (ie. a-z, A-Z, 0-9, /, + and =).
|-
| STRING || Equivalent to [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getString]].
|-
| ARRAY || Source is not filtered but is cast to array type.
|-
| PATH || Valid pathname regex that filters out common attacks. For example, any path beginning with a "/" will return an empty string. Simliarly, any path containing "/./" or "/../" will return an empty string. Dots within filenames are okay though.
|-
| USERNAME || Removes control characters (0x00 - 0x1F), 0x7F, <, >, ", ', % and &.
|}

===Filter options===
Allowed values of <options> are as follows (none of these are applied by default):

{| class="wikitable" border="1"
| JREQUEST_NOTRIM || Does not remove whitespace from the start and ends of strings.
|-
| JREQUEST_ALLOWRAW || Does not do any filtering at all. Use with extreme caution.
|-
| JREQUEST_ALLOWHTML || Does not remove HTML from string inputs.
|}

Masks can be combined by logically OR'ing them. If no filter options are specified, then by default, whitespace is trimmed and HTML is removed.

===File uploads===
Web servers already have a good deal of security around handling file uploads, but it is still necessary to take additional steps to ensure that file names and paths cannot be abused. A simplified form which requests a file to be uploaded looks like this:
<source lang="html4strict">
<form action="index.php?option=com_mycomponent/form_handler.php" method="post" enctype="multipart/form-data">
<input type="file" name="Filedata" />
<input type="submit" />
</form>
</source>
On clicking the submit button, the browser will upload the file in a POST request, passing control to Joomla which will call "components/com_mycomponent/form_handler.php". This will include code like the following. The variable $somepath must be set to some path where the web server has permission to create files.
<source lang="php">
// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die( 'Restricted access' );

// Get the file data array from the request.
$file = JFactory::getApplication->input->get( 'Filedata', '', 'files', 'array' );

// Make the file name safe.
jimport('joomla.filesystem.file');
$file['name'] = JFile::makeSafe($file['name']);

// Move the uploaded file into a permanent location.
if (isset( $file['name'] )) {

// Make sure that the full file path is safe.
$filepath = JPath::clean( $somepath.'/'.strtolower( $file['name'] ) );

// Move the uploaded file.
JFile::upload( $file['tmp_name'], $filepath );
}
</source>

===Saving a request variable into user state===
Because setting a user state variable from a variable in the request is such a common operation, there is an API method to make the task easier. This is generally safe to use because it calls [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] to obtain the input from the request, but remember that none of the input filtering calls will protect against SQL injection attempts.
<source lang="php">
$app = JFactory::getApplication();
$app->getUserStateFromRequest( <key>, <name>, <default>, <type> );
</source>
where
{| class="wikitable" border="1"
| <key> || the name of the variable in the user state.
|-
| <name> || the name of the request variable (same as the first argument of a [[Retrieving_request_data_using_JInput#Getting_Values|JInput->get]] call).
|-
| <default> || the default value to be assigned to the user state variable if the request variable is absent. The default is null.
|-
| <type> || the type of variable expected.
|}

For example, getting an integer variable called 'id' from the request with a default value of 0, then saving it into a session variable called 'myid' can be done like this:
<source lang="php">
$app = JFactory::getApplication();
$app->getUserStateFromRequest( 'myid', 'id, 0, 'int' );
</source>
instead of something like this:
<source lang="php">
$app = JFactory::getApplication();
$app->setUserState( 'myid', $app->input->getInt( 'id', 0 ) );
</source>

==Constructing SQL queries==
One of the most common forms of attack on web applications is SQL injection, where the aim of the attacker is to change a database query by exploiting a poorly filtered input variable. Injecting modified SQL statements into the database can damage data or reveal private information. It is important to ensure that when SQL statements are constructed, they are correctly escaped and quoted so that bad input data cannot result in a bad SQL statement. You cannot rely on the [[Retrieving_request_data_using_JInput|JInput]] methods to do this as they are not SQL-aware.

===Secure integers and the rest of numeric values===
With the MySQL database, numeric fields should not be quoted, so it is important that they be typecast instead. Failure to do this will leave your code vulnerable to an attacker inserting a string containing SQL data.

Depending on the type, numeric types are cast like this:
<source lang="php">
// For SQL data types: INT, INTEGER, TINYINT, SMALLINT, MEDIUMINT, BIGINT, YEAR
$query = 'SELECT * FROM #__table WHERE `id`=' . (int) $id;

// For SQL data types: FLOAT, DOUBLE
$query = 'SELECT * FROM #__table WHERE `id`=' . (float) $id;
</source>
It's a good idea to get into the habit of always typecasting integers like this even if the variable was previously obtained using [[Further information on SQL injection attacks can be found here: http://php.net/manual/en/security.database.sql-injection.php and here: [[Retrieving_request_data_using_JInput#Getting_Values|JInput->getInt]].

===Secure strings===
In the examples that follow it is assumed that $db is an instance of a Joomla database object. This can always be obtained from [[JFactory]] using
<source lang="php">
$db = JFactory::getDBO();
</source>
Strings should always be escaped before being used in an SQL statement. This is actually very simple as the [[JDatabase/quote|JDatabase->quote]] method escapes everything for you. You can also use the [[JDatabase/escape|JDatabase->escape]] method directly. The following statements are equivalent:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $db->escape( $field ), false );

$query = 'SELECT * FROM #__table WHERE `field` = ' . $db->quote( $field );
</source>
===Secure on search===
Special attention should be paid to LIKE clauses which contain the % wildcard character as these require special escaping in order to avoid possible denial of service attacks. LIKE clauses can be handled like this:
<source lang="php">
// Construct the search term by escaping the user-supplied string and, if required, adding the % wildcard characters manually.
$search = '%' . $db->escape( $search, true ) . '%' );

// Construct the SQL query, being careful to suppress the default behaviour of Quote so as to prevent double-escaping.
$query = 'SELECT * FROM #__table WHERE `field` LIKE ' . $db->quote( $search, false );
</source>

===Secure dates===
If data is to be entered into a datetime column then you can use the Joomla API to ensure a valid date format:
<source lang="php">
$date = JFactory::getDate( $mydate );
$query = 'UPDATE #__table SET `date` = ' . $db->quote( $date->toMySQL(), false );
</source>
Note that it is necessary to suppress database escaping as legitimate dates may contain characters that should not be escaped.

===Secure field names===
In the comparatively rare case where a field name is a variable, that should also be quoted using an API call:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE ' . $db->quoteName( $field-name ) . '=' . $db->quote( $field-value );
</source>

===Secure arrays of integers===
When you have an array of ids, typically used for IN() queries, you have to sanitise it also with JArrayHelper::toInteger($cid); before imploding:

<source lang="php">
...
JArrayHelper::toInteger($catId);
$query->where($db->quoteName('x.category_id') . ' IN (' . implode(',', $catId) . ')');
</source>

===Short aliases of Quote and QuoteName===
Shorter alternatives to the quote methods may also be used. The following statements are equivalent:
<source lang="php">
$query = 'SELECT * FROM #__table WHERE ' . $db->quoteName( $field-name ) . '=' . $db->quote( $field-value );
$query = 'SELECT * FROM #__table WHERE ' . $db->qn( $field-name ) . '=' . $db->q( $field-value );
</source>

==Securing forms==
Apart from cleaning input variables as described above, you can also implement a simple technique which makes it more difficult for a cross-site request forgery attack (CSRF) to succeed. This involves adding a randomly-generated unique token to the form which is checked against a copy of the token held in the user's session. By checking that the submitted token matches the one contained in the stored session, it is possible to tie a rendered form to the request variables presented.

In POST forms you should add a hidden token field using:
<source lang="php">
echo JHTML::_( 'form.token' );
</source>
This outputs the token as a hidden form field looking like this:
<source lang="html4strict">
<input type="hidden" name="8cb24ae69ffd7828ccecbcf06056e6fc" value="1" />
</source>
and places a copy of the token into the user's session, for later checking.

If you need to add the token to a URL rather than a form then you can use something like this:
<source lang="php">
echo JRoute::_( 'index.php?option=com_mycomponent&' . JSession::getFormToken() . '=1' );
</source>

In the most common scenario, you will want to check the token following a POST to the form handler. This can be done by adding this line of code to form handler:
<source lang="php">
JSession::checkToken() or die( JText::_( 'Invalid Token' ) );
</source>
If you need to pass the token in a GET request then you can check it like this:
<source lang="php">
JSession::checkToken( 'get' ) or die( JText::_( 'Invalid Token' ) );
</source>

In both cases the code will die if the token is omitted from the request, or the submitted token does not match the session token. If the token is correct but has expired, then [[JSession/checkToken|JSession::checkToken]] will automatically redirect to the site front page.

==Cleaning filesystem paths==
If there is any possibility that a filesystem path might be constructed using data that originated from user input, then the path must be cleaned and checked before being used. This can be done quite simply like this:
<source lang="php">
JPath::check( $path );
</source>
This will raise an error and terminate Joomla if the path contains a ".." or leads to a location outside the Joomla root directory. If you want to deal with the error yourself without terminating the application, then you can use code like this:
<source lang="php">
$path = JPath::clean( $path );
if (strpos( $path, JPath::clean( JPATH_ROOT ) ) !== 0) {
// Handle the error here.
}
</source>
The [[JPath:clean]] method can be used in your own code too. It merely removes leading and trailing whitespace and replace double slashes and backslashes with the standard directory separator.

==Cleaning filesystem file names==
As with filesystem paths, if there is any possibility that a file name might be constructed using user-originated data, then the file name must be cleaned and checked before use. This can be done like this:
<source lang="php">
jimport('joomla.filesystem.file');
$clean = JFile::makeSafe( $unclean );
</source>
This method removes sequences of two or more "." characters and any character that is not alphabetic, numeric or a dot, dash or underscore character. If there is a leading dot then that is removed too.
[[Category:Development]][[Category:Security]]

Manifest files

2015-04-30T13:45:22Z

Globulopolis:

{{version|2.5,3.x}}

Within Joomla there are manifest files for all of the extensions. These files include the general installation information as well as parameters for the configuration of the [[extension]] itself. Since Joomla! 2.5 {{JVer|2.5}}, there are very few differences between the manifest file formats for the different [[S:MyLanguage/Extension types (technical definitions)|types of extensions]], allowing each type to access the full power of the Joomla! installer.

==Naming conventions==
The file must be named <tt>manifest.xml</tt> or <tt><extension_name>.xml</tt> and located in the root directory of the installation package.

==Syntax==

=== Root element ===
The primary tag of the installation file is:
<source lang=xml><extension></extension></source>

This starting and closing tags are now valid for all extensions. The new tag <code><extension></code> replaces the old <code><install></install></code> from Joomla {{JVer|1.5}}. The following attributes are allowed within the tag:

{|class="wikitable"
|-
! style="width: 150px" | Attribute || style="width: 150px" | Values || Applicable to || Description
|-
| type || <code>component</code><br /><code>file</code><br /><code>language</code><br /><code>library</code><br /><code>module</code><br /><code>package</code><br /><code>plugin</code><br /><code>template</code> || All extensions
| This attribute describes the type of the extension for the installer. Based on this type further requirements to sub-tags apply.
|-
| version
| <code>2.5</code><br /><code>3.0</code> || All extensions
| String that identifies the version of Joomla for which this extension is developed.
|-
| method
| <code>install</code><br /><code>upgrade</code> || All extensions
| The default value <code>install</code> will be also used if the method attribute is not used. The <code>install</code> value means the installer will gracefully stop if it finds any existing file/folder of the new extension.
|-
| client
| <code>site</code><br /><code>administrator</code> || Modules
| The client attribute allows you to specify for which application client the new module is available.
|-
| group
| ''string'' || Plugins
| The group name specifies for which group of plugins the new plugin is available. The existing groups are the folder names within the directory <tt>/plugins</tt>. The installer will create new folder names for group names that do not exist yet.
|}

=== Metadata ===

The following elements can be used to insert metadata. None of these elements are required; if they are present, they must be a child of the root element.

<pre>
<name> – raw component name (e.g. com_banners).
<author> – author's name (e.g. Joomla! Project)
<creationDate> – date of creation or release (e.g. April 2006)
<copyright> – a copyright statement (e.g. (C) 2005 - 2011 Open Source Matters. All rights reserved.)
<license> – a license statement (e.g. NU General Public License version 2 or later; see LICENSE.txt)
<authorEmail> – author's email address (e.g. admin@joomla.org)
<authorUrl> – URL to the author's website (e.g. www.joomla.org)
<version> – the version number of the extension (e.g. 1.6.0)
<description> – the description of the component. This is a translatable field. (e.g. COM_BANNERS_XML_DESCRIPTION)
</pre>

Note: The <name> and <description> tags are also translatable fields so that the name and description of the extension can be shown to the user in their native language.

=== Front-end files ===

<source lang="xml">
<files folder="from-folder">
<filename>example.php</filename>
<folder>examples</folder>
</files>
</source>

Files to copy to the front-end directory should be placed in the <code><files></code> element. You can use the optional <code>folder</code> attribute to specify a directory '''in the ZIP package''' to copy '''from'''. Each file to copy must be represented by a <code><filename></code> element. If you want to copy an entire folder at once, you can define it as a <code><folder></code>.

=== Media files ===

<source lang="xml>
<media folder="media" destination="com_example">
<filename>com_example_logo.png</filename>
<folder>css</folder>
<folder>js</folder>
</media>
</source>

This example will copy the file(s) (<tt>/media/com_example_logo.png</tt>) and folders ( <tt>/media/css/</tt> and <tt>/media/js/</tt> ) listed to <tt>/media/com_example/</tt>, creating the <tt>com_example</tt> folder if required. You can use the optional <code>folder</code> attribute to specify a directory '''in the ZIP package''' to copy '''from''' (in this case, <tt>media</tt>).

Extensions should be storing assets they need to be web accessible (JS, CSS, images etc) in <code>media</code>. Amongst other things this feature was added as step in the progression to multi-site support and the eventual move of code files (PHP) out of the web accessible areas of the server.

Ref:
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/4CAASJqFY-k/PvPj14gP29EJ Google Groups - joomla-dev-cms thread]
* [https://groups.google.com/forum/#!msg/joomla-dev-cms/uNmhX98sKbE/p8p68Jke680J Google Groups - joomla-dev-cms thread]

=== Administration section ===

<source lang="xml">
<administration>

</administration>
</source>

The administration section is defined in the <code><administration></code> element. Since only [[S:MyLanguage/Component|components]] apply to both the [[S:MyLanguage/Site (Application)|site]] and the [[S:MyLanguage/Administrator (Application)|administrator]], '''only component manifests can include this element'''.

==== Back-end files ====

Files to copy to the back-end directory should be placed in the <code><files></code> element under the <code><administration></code>. You can use the optional <code>folder</code> attribute to specify a directory '''in the ZIP package''' to copy '''from'''. See ''Front-end files'' for further rules.

==== Menu links and submenus ====
{{dablink|'''Version Note:''' Prior to Joomla 3.4 not having a menu tag in your XML file still led to a menu item being created. This bug was fixed in Joomla 3.4 so if no menu item was created then no admin menu item is created for the component.}}

<source lang="xml">
<menu>COM_EXAMPLE</menu>
<submenu>

<menu link="anoption=avalue&anoption1=avalue1">COM_EXAMPLE_SUBMENU_ANOPTION</menu>
<menu view="viewname">COM_EXAMPLE_SUBMENU_VIEWNAME</menu>
</submenu>
</source>

The text for the main menu item for the component is defined in the <code><menu></code> item, a child of <code><administration></code>. A <code><submenu></code> element may also be present (also a child of <code><administration></code>), which may contain more menu items defined by <code><menu></code>.

Additionally, each <code><menu></code> item can define the following attributes:

{| class="wikitable"
! style="width: 150px" | Attribute || Description
|-
| link || A link to send the user to when the menu item is clicked
|-
| img || The (relative) path to an image (16x16 pixels) to appear beside the menu item.
<u>Must be an url compatible as a file too (e.g. no spaces) !</u>
|-
| alt ||
|-
| ''string'' || An URL parameter to add to the link. For example, <code><menu view="cpanel">COM_EXAMPLE</menu></code> in com_example's XML manifest would cause the URL of the menu item to be <tt>index.php?option=com_example&view=cpanel</tt>.
|-
|}

The value inside the tag is the menu's label. Unlike Joomla! 1.5, you can not use a natural language string. For example, if you would enter "Example Component" instead of COM_EXAMPLE, it would result in your component name appearing as example-component in the menu and you would be unable to provide a translation. In order to provide a translation you need to create a file named en-GB.com_example.sys.ini in administrator/languages/en-GB (you can use the manifest's <code><languages></code> tag to copy it during installation) or in administrator/components/com_example/language/en-GB. In the latter case, you must not include the translation file in the <code><languages></code> tag. As long as you have placed the language directory in your <code><files></code> tag, it will be copied along when the component is being installed.

The contents of that file should be:
<source>
COM_EXAMPLE="Example Component"
COM_EXAMPLE_SUBMENU_ANOPTION="Another Option"
COM_EXAMPLE_SUBMENU_VIEWNAME="Another View"
</source>

Please note that the language string must be enclosed in double quotes, as per Joomla!'s translation standards. Important note: Joomla! 1.6 and later sorts the Component menu items based on the actual translation of the key you supply in your XML manifest. This means that the sorting order is correct no matter what you call your translation key and no matter which language the site is being displayed in. Essentially, Joomla! 1.6 fixed the wrong sorting of the Components menu experienced under Joomla! 1.5 for the majority (non-English speaking!) of Joomla! users.

=== Configuration ===
{{warning|Components '''do not support''' configuration definitions '''in the manifest'''. This is a way implemented in Joomla! 1.5. They can define configuration options for multiple levels using [[Component configuration metadata]].}}
The <code><config></code> element, a child of the root, describes the configuration options for the extension. If applicable, the options will be shown by the appropriate Manager (Plugin Manager, Module Manager or Template Manager). '''Configuration options can also be defined in a separate file named <code>config.xml</code>. Its root element should be <code><config></code>.'''

{{:XML JForm form definitions}}

=== SQL ===

<source lang="xml">
<install>
<sql>
<file driver="mysql" charset="utf8">sql/example.install.sql</file>
</sql>
</install>
<uninstall>
<sql>
<file driver="mysql" charset="utf8">sql/example.uninstall.sql</file>
</sql>
</uninstall>
</source>

In the above example, we put the SQL files in the <tt>admin/sql</tt> folder of the installation package. You have to include the <tt>sql</tt> folder in the administration files (as described in ''Back-end files'').

You can execute SQL during the installation and/or uninstallation using the <code><install></code> and <code><uninstall></code> elements, respectively. A <code><sql></code> element should appear as a child of these elements. <code><sql></code> can contain any number of <code><file></code> elements, each defining a single SQL file to execute. Their database driver types are described by the <code>driver</code> attribute, their character sets by the <code>charset</code> attribute.

==== Update of the SQL schema ====

<source lang="xml">
<update>
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
<schemapath type="sqlsrv">sql/updates/sqlsrv</schemapath>
</schemas>
</update>
</source>

Since 1.6, there is also an <code><update></code> tag, which allows you to provide a series of SQL files to update the current schema.

=== Language files ===
In Joomla! 1.5, extension developers had to put extension language files in the Joomla! main language file, using the <languages>..</languages> tag as shown below. '''This method can still be used in''' {{rarr|2.5,3.x}}.

<source lang="xml">

<languages folder="langfiles">
<language tag="en-GB">en-GB.com_example.ini</language>
</languages>
</source>

Since Joomla! 1.6 it has been encouraged placing your extension's language files in your extension folder. Joomla! will then automatically load your extension's language files.

By storing extension language files in the extension folder, you gain the benefit of isolating and protecting your extension's language files. For example, an administrator removes a language from their Joomla! installation. Your extension's language files will not be removed. They will remain in place and will be available if the language is installed again.

The structure of the language folder for frontend and backend is the same. You put them in the language tag (e.g. '''en-GB''' ) of each language in your language folder i.e. '''language/en-GB/'''. You have to specify those folders in the front-end and back-end files too.

In your manifest you simply include the ''''language'''' folder in your files section, the sub-directories for each language automatically be copied. Inside the <files> group you simply add a <folder> element alongside the items in the '''<files>''' group as shown in this example:

<source lang="xml">
<files>
<filename plugin="alpha">alpha.php</filename>
<folder>sql</folder>
<folder>language</folder>
</files>
</source>

It is also notable that both ways can work together. Here is an example from core:
<source lang="xml">
<files>
<filename plugin="languagecode">languagecode.php</filename>
<filename>index.html</filename>
<folder>language</folder>
</files>
<languages>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.ini</language>
<language tag="en-GB">language/en-GB/en-GB.plg_system_languagecode.sys.ini</language>
</languages>
</source>

The advantages of this solution are the following:

All ini files present in the core folder have precedence over the files in the extension language/ folder.
For example a sys.ini file will always be loaded from core folders in back-end if it exists, except when installing an extension which contains a sys.ini file in a language folder. In that case and only that case, the sys.ini file in the extension folder will display its translated content at install time. This is very handy as a developer can have 2 sys.ini files with different contents. A description of the successful install as well as a tutorial in back-end for example.

Also, it is much easier for a user needing an ini file for an extension that does not provide it in the language desired, to add it in the main folders. No risk for it to be deleted in case of uninstalling the extension by mistake or any other reason.

See also:
*[[J2.5:Making non-core language packs|Making non-core language packs]]
*[[Creating language packs for extensions in Joomla 2.5]]

During development you can turn on language debugging in the Joomla! global configuration. So you can investigate if a problems arises. As of 3.2, this is necessary to help debug as en-GB is '''always''' loaded first when not in debug mode to prevent displaying Constants.

=== Script file ===

<source lang="xml">
<scriptfile>example.script.php</scriptfile>
</source>

An optional '''script file''' (PHP code that is run before, during and/or after installation, uninstallation and upgrading) can be defined using a <code><scriptfile></code> element. This file should contain a class named "<element_name>InstallerScript" where <element_name> is the name of your extension (e.g. com_componentname, mod_modulename, etc.). Plugins requires to state the group (e.g. plgsystempluginname). Library packages do not support scriptfiles. The structure of the class is as follows:

<source lang="php">

class com_componentnameInstallerScript
{
/**
* Constructor
*
* @param JAdapterInstance $adapter The object responsible for running this script
*/
public function __construct(JAdapterInstance $adapter);

/**
* Called before any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param JAdapterInstance $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function preflight($route, JAdapterInstance $adapter);

/**
* Called after any type of action
*
* @param string $route Which action is happening (install|uninstall|discover_install|update)
* @param JAdapterInstance $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function postflight($route, JAdapterInstance $adapter);

/**
* Called on installation
*
* @param JAdapterInstance $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function install(JAdapterInstance $adapter);

/**
* Called on update
*
* @param JAdapterInstance $adapter The object responsible for running this script
*
* @return boolean True on success
*/
public function update(JAdapterInstance $adapter);

/**
* Called on uninstallation
*
* @param JAdapterInstance $adapter The object responsible for running this script
*/
public function uninstall(JAdapterInstance $adapter);
}

</source>

=== Update servers ===

<source lang="xml">
<updateservers>
<server type="extension" priority="1" name="Extension Update Site">http://example.com/extension.xml</server>
<server type="collection" priority="2" name="Collection Update Site">http://example.com/collection.xml</server>
</updateservers>
</source>

Update servers can be defined in the <code><updateservers></code> element, a child of the root. This element may contain one or more <code><server></code> element, each describing a location to fetch updates from. Each <code><server></code> item can define the following attributes:

{| class="wikitable"
! style="width: 150px" | Attribute || style="width: 150px" | Values || Description
|-
| type || <code>extension</code><br /><code>collection</code> || The update server type
|-
| priority || ''integer'' || The priority of the update server
|-
| name || ''string'' || The name of the update server
|}

More info:
* [[J2.5:Developing a MVC Component/Adding an update server|Building a Joomla! Extension - Adding an update server]]
* [[J2.5:Managing Component Updates|Managing Component Updates in Joomla 2.5]]

== Examples ==
For a real-life example, see [https://github.com/joomla/joomla-cms/blob/2.5.x/administrator/components/com_banners/banners.xml the manifest of the Banner component in the latest version of Joomla! 2.5].

The Joomla testing process uses several extensions to test whether the installer works correctly. The latest versions of the manifests of these extensions are:

* [http://svn.joomla.org/project/cms/development/trunk/tests/_data/installer_packages/com_alpha/alpha.xml com_alpha manifest]
* [http://svn.joomla.org/project/cms/development/trunk/tests/_data/installer_packages/mod_alpha/mod_alpha.xml mod_alpha manifest]
* [http://svn.joomla.org/project/cms/development/trunk/tests/_data/installer_packages/plg_system_alpha/alpha.xml plg_system_alpha manifest]
* [http://svn.joomla.org/project/cms/development/trunk/tests/_data/installer_packages/tpl_simple/templateDetails.xml tpl_simple manifest]
* [http://svn.joomla.org/project/cms/development/trunk/tests/_data/installer_packages/lng_xx-XX/xx-XX.xml lng_xx-XX manifest]

== Contributors ==
*[[User:akede|Alex Kempkens]]
*[[User:dperaza|Daniel Peraza]]
*[[User:nikosdion|Nicholas K. Dionysopoulos]]
*[[User:mrs.siam|Prasit Gebsaap]]
*[[User:cppl|Craig Phillips]]

[[Category:Extension development]]
[[Category:Specifications]]
[[Category:Needs to be marked for translation]]