web notes - a blog

• A partnership doesn’t imply direct revenue generation or sales support
• A partnership should help all parties reach their goals
• A partnership should raise the level of service for the end user
• A partnership should be respected by all parties
• Partnership participation costs should be clearly defined and understood by all parties
• Levels of participation should be allowed, and partners should be able to ‘opt-out’ of opportunities

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.

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.

A blog without any categories may do well with search engines, but it won’t help site visitors find related content.

If the objective of the blog is to provide a collection of helpful material, organization is vital. Create appropriate categories and identify posts accordingly. Add new categories as the blog matures.

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.