Category: Systems

Technical Instructions: How to use my Form Content Display Wizard

So, to use my plugin to any form or content,

Separate content chunks:
Wrap the content in div containers with unique ids begining with “step_xxx”  where xxx should be a detailed way to identify the content such as “step_intro” and  “step_personal_info”

If the path is non branching, the plugin will create buttons for “back” and “next” named “stepDownButton” and “stepUpButton” . It will look for the second to last step and put a submit, and the last step is the confirmation. To create a custom path, branch, or skip a step, just create a button named “stepDownButton” and “stepUpButton” . Give the button an onclick of stepUp(‘stepname’) or stepDown(‘stepname’) to make the button skip to a certain step.

Table of contents
The plugin will use the first element inside the step as description for the table of contents. You can use the attribute stepdesc on the step_xxx element as a custom title for the toc. The toc will be appended to the first step unless you make a custom toc using a container with id of “tableofcontents”. This can be disabled by …..

Form elements and Validation
To provide “empty field” validation to form elements in a step, just add the class “required” to the element. Place the class “email” to validate an email address on one input element. You can add class “match” to two elements in a step and they will have to match each other. Give the elements a unique ID and a good name attribute, and the plugin will create placeholders for the text input elements from the name.
NOTE: it seems like the name attribute is the perfect place to put a readable descriptive title that could be used in creating the labels, and for  summary display. NOTE: it seems like moving to the new html5 text inputs for validation such as email tel, then if input type = email, wouldn’t need a class selector.Just a thought for moving forward with

Data summary
In the second to last step, the plugin will set the the “NEXT” button onclick to stepUp(‘submit’);  The plugin will add a summary of the data the user entered so they may go back and make any changes. You may choose a custom display of the summary by putting an element with id “formsummaryarea” into this step. The plugin will omit any empty or hidden fields from the summary, and you can put class “nosummary” to omit any other items from the summary.

Submit and final confirm
In the final step, you should place your  final confirmation text there. This will tell the user the results of their data submit, success or error.  When user is ready, the script will submit the form data, and move to the final confirmation.

 

 

Themeing the elements

To theme the elements, just add classes to items in the ui view using jquery :

This will add a Panel effect to the divs—
$(‘div[id^=”step_”]’).addClass(“softblackgradient blackbottomrightboxshadow mediumallaroundpadding”);

The buttons wont work to style this way cause they aren’t in dom yet. To theme the buttons, you need to  set these global variables before you call to include the plugin.:

I feel that the “Begin”  button should look very different from the Next and Back buttons:
beginbuttonclass = “button roundedcorners success mediumallaroundpadding”

Here is to style the step up and step down buttons:
stepupbuttonclass=”button oval success smallallaroundpadding”
stepdownbuttonclass=”button oval alert smallallaroundpadding”

The “Submit” button needs to also look very different from the step up and down buttons.
style it like this: submitbuttonclass=”button roundedcorners mediumallaroundpadding success”

 

If you have put in custom buttons to go to non linear paths, make sure to still give the the names of stepUpButton and stepDownButton. Then you can select and style them as well using the jquery selector.

Theres tableofcontents to layout the toc, and  highlightstep to control the highlighted step. This is proving very difficult to get out of the plugin, since the toc relies on the scripts. There are classes yellowhighlight, and  mediumtext that will need to be declared in the ui view that is using the plugin.

Web Form Security Practices

We have had a lot of attacks to our web forms here at SVC. I am the paperless applications developer, so the task of keeping them safe and secure falls into my daily operations. An un secure form can let an attacker do many things to ruin someones day, such as sending unsolicited emails to all the staff and students. Some of the common practices to keep the “bots” from breaking into a web form are:

CAPTCHA
This technique provides the user with a series of image “keys”  that they must “unlock” before they can submit the web form. This is a  good way to slow down the bots, but since they don’t get tired, and can hammer away at the form many times each second, they can eventually bypass this technique. Another problem with captcha, and a very important one, is regarding the user experience. Some captchas are impossible to read, and take several tries for a normal user to get correct. This can really damper the user experience and create a situation where the user will just leave instead of taking the time to keep trying to unlock the captcha keys. As stated by the w3, “This type of visual and textual verification comes at a huge price to users who are blind, visually impaired or dyslexic. Naturally, this image has no text equivalent accompanying it, as that would make it a giveaway to computerized systems. In many cases, these systems make it impossible for users with certain disabilities to create accounts, write comments, or make purchases on these sites, that is, CAPTCHAs fail to properly recognize users with disabilities as human.”

So, what else can I do to help keep the bots from submitting forms?

1: Try to make sure that the form is submitted from the form page, because the bots usually submit directly to the form action. Put some kind of trigger in the form submit actions that look for a referring address or a session variable.

In classic ASP we have the Request.ServerVariables collection that can get some important information, and if the form data has not come from the form page, we know its a bot, and can secretly send a security alert to the admin, while not letting the bot know its been busted.

Request.ServerVariables("URL"), SCRIPT_NAME, and PATH_INFO

should all contain the form’s address, and should show that the form was submitted from the proper location.

Request.ServerVariables("SERVER_NAME")

should be checked for the proper domain, indicating whether the form was properly posted from my server. I could create an include to be used before each form submission to check for coming from my server.

These could be put into hidden fields and submitted with the form, then checked for validity before processing and submitting the form. Also a session variable might be a good way to track these from form submit to data capture.

In the form capture logic, we could look for Request.ServerVariables(“HTTP_REFERER”) to ensure that the data has come from our form page.

So, lets try some of this junk and see if it helps out.
First, lets set a session of “formuser” with a value of Request.ServerVariables(“URL”) when the user accesses the form, and then check for that session in the form submit logic. If there is no session, then this data did not come from our form.