Category: "Web Applications"

Risks of Web-Based Application Management

Many web applications can be configured through the application. This is extremely valuable, especially for users that don’t have SSH access and don’t want to use FTP. The danger is that in order for web access to work, the web server must have write privileges into the directories. This creates a security risk.

Set the file permissions to 644, and the owner to the account owner, not the web server. This has an added benefit of limiting write privileges for configuration files to people with SSH/FTP access, not just application administration.

Try to set up the web server such that requests for files in compiled or cached template directories are denied for all users. In many cases, this will work, because template files are often included into other files at runtime. In the event that malicious files are placed in the directory, they cannot be served.

Remove the application name and version data from the page source. Suppress the delivery of detailed web server headers. The less information delivered, the better.

Change the admin access URLs from the default or standard names (such as admin), to something else. Delete or rename the installation directory or files. Be sure to use secure passwords.

Always disable directory display, to prevent people from browsing through the file system.

Be sure the server software is up to date, use mod_security (modsecurity.org), keep PHP up-to-date, and especially, the applications. Monitor the access and error logs. Backup the database and filesystem frequently (automate it). Periodically, SSH in to check the filesystem.

AJAX Page Load Improvement

The application I am working on has several very complex pages, which take some time to render in the browers. I used the link above to create a ‘loading‘ gif (with great thanks to the authors and contributors). Set up a div to contain the image and ‘Loading, please wait …‘ text, with z-index set to -1. Added dojo.OnLoad() to hide the loading div and display the main div.

The effect of these changes is to prevent display of the page content until dojo had fully rendered it.

A side effect is that the page seems to load and display much more quickly. I suspect this is because the browser doesn’t have to display the page as it is being rendered.

dojo - Smarty - PHP - Synchronizing client- and server-side validation

The following architecture with Smarty and dojo allows you to the client and server synchronized for validation for RIA/PHP applications.

Each input has 4 characteristics defined in a (PHP) .ini file -

V_input_name = regExp (usually includes length)
L_input_name = max length
R_input_name = true or false (required or not)
T_input_name = type of input data in database, used to support documentation



Each input also has 3 characteristics defined in a Smarty .conf file, and there is a .conf file for every language (.ini be under languages)

E_input_name = error message
I_input_name = invalid message
P_input_name = prompt message

Smarty constructs the input tags like so:

<input type="text" dojoType="dijit.form.ValidationTextBox"
    name="input_name" id="input_name"
    regExp="{#V_input_name#}"   
    errorMessage="{#E_input_name#}"
    promptMessage="{#P_input_name#}"
    invalidMessage="{#I_input_name#}"
    length="{#L_input_name#}" />



There is a simple javascript validation that accepts an array of inputs and tests if they are valid with input_name.isValid(), displaying input_name.errorMessage if not, and cancelling the submit.

On the server side, there is a loop that tests the inputs against the same strings:

foreach ($aInput as $k => $v)
  if (isset($aIni['V_'.$k]))
  { 
    $sInput=trim($v); 
    if (isset($aIni['R_'.$k])
    if (($aIni['R_'.$k]=='true') && ($sInput=='')) /* Test for required */
      return false;
    if (!filter($aIni['V_'.$k],$v))  /* flter ensures data complies with regexp */
        return false;
   }



This allows the client-side code to help the user enter valid data, and allows the server-side code to protect the server by disallowing or discarding data that isn’t valid.

Please note that page-level validation, where the required state and content of data may vary based on other inputs must be reflected at both the client and server side.

What you can do with FireBug

  • Debug javascript
  • Examine the DOM tree
  • Understand the CSS
  • Change the CSS in the browser to see its effect
  • See the layout of the page
  • Determine the dimensions of page elements
  • See the page components and understand the page load process
  • View the HTTP headers
  • Evaluate javascript expressions and commands interactively
  • Use debug write (console.debug) statements to issue debug data
  • Add breakpoints
  • Profile your page

If you use it, all the time, contribute. Ask your employer to support it.

Log ALL Errors

Graceful error trapping and display is important, both during development and after deployment. It is also good to have debug control that is manageable through environment variables. One nice solution is to use SetEnv in .htaccess or a .conf file.

Regardless of the trap and display code, be sure to log all errors, so you can resolve them if they occur. Check the error log (usually /etc/httpd/logs/error_log) frequently.

Along those lines, although using isset in Smarty template will not cause an error, if the Smarty variable inside the call is not set, a PHP will be thrown (http://smarty.net/manual/en/language.modifier.default.php). Possible solutions:

  • Do nothing - disk space is cheap and the logs get rotated (this is the wrong answer)
  • Initialize all Smarty variables for the templates in the PHP (a good answer)
  • Use PHP to initialize the template variables within the template, using {php} tags (also a valid approach)
  • Use AJAX to populate forms (may be much more difficult and take longer)

The best approach depends on the application architecture, and may vary by template within the application.

It is good to look at the compiled templates to see how they are constructed.