Navigation

• Länkar
• Trafik
• Platser
• Webbdesign
• Databaser
• Programmering
• Visualisering
• Utbildning
• Säkerhet
• Arbete
• Fotografi
• Diverse
• Security
  

• Login/Logout
• Language Selection
• Create Account
  

Quick Search
»
Advanced Search »

PHP-mailer technical information

Recipients

One frequent question we receive is "how to go about having different recipients receiving the same form". One example question is from "Gregg":


In short, this user wants to send the person who filled in the form an e-mail. This is pretty simple to do. Using the sample form as an example (form.html), all you need to do is edit the file:

/_lib/form.config.php

The following two lines:

 $_POST['replyEmailOnSuccess']     = 'form.replyemailsuccess.html';
$_POST['subjectEmailOnSuccess']   = 'Email Submission succeeded';

Then create a file:

/_lib/form.replyemailsuccess.html

that looks similar to the form itself. A pattern of how to do this is in the file
/_lib/replyemailsuccess.html

and a few notes on this:
Have a look at the sample we include with the software. You will notice that there are no form tags, no input fields (or other form elements). In place, we have place holders - for example "{thanksMessage}". It looks for a form variable named "thanksMessage" and will do the string replacement automatically on the form submission. You can replace all the form variables with these place holders to get the form data the user typed in into the success reply email.


Another example is a human resources employment application form. You may want to direct the form to different location managers based on a location drop down in the form. Here's how you accomplish that: Let's say you have a form called employmentapplication.html with a location drop down field containing two choices: New York (which returns NY) and Texas (which returns TX). We'll assume the field name is "location". In your /_lib/employmentapplication.config.php file, insert code that looks like:

 switch ( $_POST['Location'] ) {
    case "NY":
      $_POST['recipient'] = "nymanager@yourdomain.com";
      break;
    case "TX":
      $_POST['recipient'] = "txmanager@yourdomain.com";
      break;
    default:
      $_POST['recipient'] = "hrmanager@yourdomain.com";
}

That's it. Then based on the location selected by the user, the appropriate HR manager will receive the form submitted.

About sanitizing form data

In PHPMailer-FE version 4.0.5, we added the ability to sanitize or clean up user-submitted form data.

The file responsible for this is: _lib/inc.sanitize.php

This script is not entirely of our making. The core of the script is authored by someone else, and we have no idea who. We have modified this script to function with PHPMailer-FE.

In essence, it will "clean-up" or sanitize the data users type into the form.

The specific functionality is (in no specific order):

• will remove hex values
• will stop directory traversal
• will stop MySQL injections and MySQL comments
• will stop base64 encoding
• will remove null characters
• will do basic HTML entities checks and conversion
• will convert all tabs to spaces
• will convert all PHP tags to safe HTML entities
• will convert all XML tags to safe HTML entities
• will convert all Javascript (and other script) tags to safe HTML entities
• will compact all exploded words
• will remove all Javascript (and other scripts) from links and images
• will sanitize all bad HTML code
• will sanitize all bad script code
  

Essentially, if enabled, it will eliminiate and/or minimize the impact of hacker access to forms to generate cross site scripting attacks, database injection or attacks, and javascript/vbscript (etc) malicious use.

The sanitize utility is not intended to be used for data validation or formatting.

Order of processing in PHP-mailer-FE

Those of you that want to know the order of processing for PHPMailer-FE:

• note: discusses only major functionality
  
• PHPMailer-FE gets handed the form data
• checks if the form is handing the data as $_GET or $_POST
  if ANY $_GETS found, PHPMailer-FE aborts.
• gets the IP address and Remote Host of the browser sending the form data
• displays the processing image
• converts all $_POST data as regular PHP variables
• reads and converts 'default.config.php' (converts all $_POST
  data as regular PHP variables ... overwrites any previous duplicates)
• CONDITIONAL:
  if getenv('HTTP_REFERER') is not blank OR $_POST'referer' is set:
  • reads and converts the form config file (converts all $_POST
    data as regular PHP variables ... overwrites any previous duplicates)
• processes the Turing test
• checks if set 'referers' and if the form data submitted is in approved 'referers' ...
  will exit if not found in list
• checks email banlist ... will exit if the email address filled in the form is found
• checks IP/Remote Host banlist ... will exit if the IP address or Remote Host is found
• processes "required" fields
• processes file uploads (note: will check for errors and include a field in the email
  to the recipient if any errors are found)
• processes local file attachments
• parses the form data
• builds the environment report
• builds and sends the email(s)
• sends a copy to the $_POST'email' if that field is available and the field
  send_email_copy is set
• sends the email reply on success (if successful) and uses the template file found
  in $_POST'replyEmailOnSuccess'
• processes 'default.plugin.php' (NOTE: there should be NO echo or print statements
  if the default.plugin.php if this is a Flash form or the Flash form will not receive
  the appropriate return code)
• processes the form specific plugin (NOTE: there should be NO echo or print statements
  if the default.plugin.php if this is a Flash form or the Flash form will not receive
  the appropriate return code)
• exits if this is a flash form
• redirects to Thank You for your submission page (either generated page or redirects
  based on $_POST'redirect')
  

About Forms Security

Our company, Worx International Inc., has been researching PHP server side validation. This research was initiated because client side validation simply doesn't work consistently. All client side validation is based on Javascript. That applies as well to Ajax, and Javascript Frameworks (like Mootools, jQuery, etc.). The problem with client side validation is that to deliver garbage to your inbox and hack your forms, all users have to do is disable Javascript in their browser. There are ways around this such as using Javascript to echo the Submit button (ie. no Javascript, no Submit button), but these are obtrusive and counter-productive for those users who legitimately do not have Javascript or disable Javascript for personal reasons. The only solution that is effective and works all the time is a server side validation strategy. We've found a number of very good server side validation products. Here's a summary of the PHP scripts we found:

Autoform - http://www.greaterscope.net/projects/Autoform License: MIT. Recently I have been working with the developer of PHP Autoform. Autoform is quite unique ... it is both a form generator, and validates user input on the server-side. It works quite well with PHPMailer-FE and has unlimited potential to secure your forms and eliminate, or greatly minize, spam and junk mail from your website forms. To show the capabilities of Autoform, I have put up several sample forms of my own, plus the example forms from the Autoform package. Please have a look at: http://www.worxware.com/autoform/ ... please note this are very basic sample pages to show Autoform in action. I also have several modifications and a client-side validator running with the samples. If you have need of customization to Autoform, I would encourage you to contact the developer through the website http://www.greaterscope.net/projects/Autoform.

HTML Form - http://stefangabos.blogspot.com License: unknown, but LICENSE file says you can use it for personal or commercial applications License note 1: the author includes a BUT ... only if you send him the link where you are using the code License note 2: the software is distributed with X Templates (LGPL/BSD), and XSS Clean (from the PHP Code Igniter product, with permission) HTML Form is the most robust of all the products tested. It is both a form generator, and validates user input on the server side. It is unique in the products tested that it also uses X templates that can render forms from very basic to extremely complex layouts. HTML Form is effective. I have not found any condition in which HTML form does not work.

.... and a quick note about clonefish: we have not included clonefish here because the license type for the free cannot be determined. If we are not able to determine our rights in using the software, it isn't worth downloading. You may wish to look into it, though at http://www.phpformclass.com/.

Summary: As a server-side validators for forms, these product should have your interest. It's the ideal way of dealing with hackers and spammers accessing your forms for their dirty payloads and filling your inbox with garbage. The beauty of this solution is that regardless of the user's Javascript settings in their browser, validation takes place at the server BEFORE the form gets processed.

Note: As of January 3 2011, we will be starting testing of our own server-side validation script.