Guild Blogs

Introduction

Ask a group of web developers about the critical importance of data validation and you’re sure to get many heads nodding, for they know all too well the security of their own job depends on how successful they are at executing this task. Sites that lack data validation features are sure to invite errors downstream as that information is stored, processed, and ultimately, relied on erroneously.

Since the inception of web sites that did more then simply act as fancy brochures there’s been scant resources for the web developer to utilize for this purpose, and often times, getting data validation to work properly felt like fitting round pegs into square holes to effectively provide a web site with the proper data validation necessary to capture reliable information.

Background

One of the truisms that most web developers I’ve spoken to agree on is that end-users of a website are innately ignorant and will mess up data entry in a web form if given the chance. It is therefore the job of web developers to make his or her pages utilize a client-side scripting language, such as JavaScript to verify the data being entered. What needs to be validated is often up to the web developer. It is his or her duty to determine how extensively he needs to fool-proof his web form. Often times you just need to make sure that required fields are entered. Other times you need to ensure that the correct data type is entered; and still other times you need to make sure a user's input conforms to a certain standard (such as telephone numbers, social security numbers, etc.).

Let's look at an example. Let us say that you are wanting to collect information from your users about how they rate your site. You may have a form asking for the following fields:

• Their full name
• Their e-mail address (which you make optional)
• A rank for the site ranging from 1 – 10

We would want to write a JavaScript function to ensure that the name field had a value in it, and that the site ranking had a value between 1 and 10 in it. Let's take a look at what the JavaScript would look like (code is incomplete due to space and tag usage limitations):


SCRIPT LANGUAGE="JavaScript"

function ValidateData() {
var CanSubmit = false;
// Check to make sure that the full name field is not empty.
CanSubmit = ForceEntry(document.forms[0].txtName,"You supply a full name.");
// Check to make sure ranking is between 1 and 10
if (CanSumbit) CanSubmit = ValidRanking();
return CanSubmit;
}
/SCRIPT
And submitted here:
FORM NAME="frmSiteRanking" METHOD="GET" ACTION="SiteRanking.asp" ONSUBMIT="return ValidateData();"


This is one small example of validating data prior to the introduction of ASP.NET. In this world, developers had to write all of their own validation routines and cut and paste them in the various ASP scripts that needed to employ various validation techniques. Imagine needing to write similar scripts for every last form input value that an end-user might mess up. All in all, it was a real headache. This is where ASP.NET form validation server controls come into play.

ASP.NET to the Rescue

Validation Web controls are ASP.NET Web controls designed specifically to validate form field entries. For example, ASP.NET contains a RequiredFieldValidation control, which, as its name suggests, can be used to ensure that the user enters a value into a form field (such as a TextBox). Specifically, ASP.NET provides the following form field validation controls:

1. RequiredFieldValidator - Checks to make sure the user entered a value.
2. CompareValidator - Compares a form field's value with the value of another form field using relations like less than, equal, not equal, etc.
3. RangeValidator - Ensures that a form field's value is within a certain range.
4. RegularExpressionValidator - Makes sure that a form field's value corresponds to a specified regular expression pattern.
5. CustomValidator - Checks the form field's value against custom validation logic that you, the developer, provide.
6. Validation Summary - display a summary of the results from all validation controls on the page.

By default, page validation is performed when a control, such as button, ImageButton, or LinkButton is clicked. You can prevent validation from being performed when a button control is clicked by setting the CausesValidation property of the button control to false. This property is normally set to false for a cancel or clear button to prevent validation from being performed when the button is clicked.

Let’s take a closer look at one of these controls in greater detail.

RequiredFieldValidator

Footprint

asp:RequiredFieldValidator
id="ProgrammaticID"
ControlToValidate="ProgrammaticID of control to validate"
InitialValue="value"
ErrorMessage="Message to display in ValidationSummary control"
Text="Message to display in control"
ForeColor="value"
BackColor="value" runat="server"
/asp:RequiredFieldValidator


Use the RequiredFieldValidator control to make an input control a mandatory field. The input control fails validation if the value it contains does not change from its initial value when validation is performed. This prevents the user from leaving the associated input control unchanged. By default, the initial value is an empty string (""), which indicates that a value must be entered in the input control for it to pass validation.
Note Extra spaces at the beginning and end of the input value are removed before validation is performed. This prevents a space being entered in the input control from passing validation.

Example
The following example demonstrates how to use the RequiredFieldValidator control to make a TextBox control a mandatory field:

form runat="server"
Name:asp:TextBox id="Text1"
Text="Enter a value" runat="server"
asp:RequiredFieldValidator id="RequiredFieldValidator1" ControlToValidate="Text1"-->links validator to text box
Text="Required Field!"
runat="server"
asp:Button id="Button1" runat="server" Text="Validate"

Conclusion

Instead of the web developer needing to write extensive client-side JavaScript to validate this field the Validation Control does much of the work itself by linking validation rules to any HTML input control requiring similar examination. Significant time is saved, and the developer can focus on what really counts… the actual content being developed, instead of the minutia of old-style, client validation code.

Jon Udell wrote a piece
(and another)
about some technology Jonathan
Edwards at SubText is putting together
(demo).

Looking at the demo gets me excited about the future of writing code. I get tired of fighting text while trying to express an algorithm. It also reminded me of Prograph CPX which I used for many years. Prograph was based on the data flow graph that could be built of any algorithm and made a lot of sense. Turns out for Pictorious that being a niche language provider is not very profitable and they moved into professional services a number of years ago and in fact seems to have disappeared.

Via Simon:

IE allows script to read the contents of the clipboard! Some nefarious person
could easily grab your clipboard contents and post them back to their
server.

A fix from the comments:

Tools -> Internet Options,
Security.

In the appropriate Custom Level section(s):
Scripting,
Allow paste operations via script option
Set this to "Disable" or "Prompt".

Scott Came will be attending the winter meetings of the IJIS Institute, and will be participating in the XML Advisory Committee meetings.

From Haacked  How Constant Are Your Constants in .NET

When one assembly references a constant in another assembly, the compiler will embed the value of that constant into the assembly.

This could really lead to some hard to find bugs. Imagine deploying just the library with the changed constant, and none of you applications that depend on the constant changing their behavior!

... it would be better to make this a public static read only variable...

Haaked's recommendation is a good work-around for those "constants" that might need to be changed during the lifetime of the application.

This reminds me of my previous post on Public Variables In VB.NET Modules in that the compiler does unexpected things to your code.

the spurious pundit has a really good post on how hard it is for manager types to do a good job of telling people what they want done.

Snippets:

First off, there's the mechanics of how to do it. What tools does he need? You know that there's a hammer and nails in the back of the supply closet. He doesn't, and it's fair of him to assume that you wouldn't have asked him to do something he didn't have the tools for. He looks around his desk, and he's got a stapler and a tape dispenser.

There is also another way this can go wrong, particularly with a certain breed of eager young programmer. You find that he's gone down this path when your boss comes by the next week to ask about this purchase order for a nail gun. So you talk to your guy and discover that he's spent the last week Googling, reading reference works, and posting to news groups. He's learned that you hang pictures on a nail driven into the wall, and that the right tool for driving nails into walls is a high-end, pneumatic nail gun. If you're lucky, you can point out that there's a difference between picture-hanging nails and structural nails, and that a small, lightweight hammer like you have in the supply closet is really the right tool for the job. If you're not lucky, you have a fight on your hands...

So now we get into higher-level design issues. Where should the picture go? At what height should it be hung? He has no way of judging any of this, and again, it's not as obvious as you think.

In my previous post we had some good discussion regarding rule # 1:

The best product managers follow the Pragmatic Marketing maxim: Your opinion, while interesting, is irrelevant. Always use market facts to decide the best course of action.

The general sense of the responses was that this rule doesn't allow for innovation. So I tracked down Steve Johnson who was the source of the rules for comments. Here is his response (with permission):

Amazing that "use market facts" is somehow being misinterpreted as "Ask people what they want." The internet solved a huge, documented problem; people didn't ask for it by name but they had long asked for a solution to the problem of connecting businesses and consumers with a single connection point.

True, I don't rely too heavily on product management encouraging innovation; more often I need them to curb unfocused featureitis disguised as innovation.

Steve has a good point here. In the past I've noticed a similar disconnect between the desire to have "innovative" products and a willingness to collect data. Somehow people get to the point where what they believe is more important. This doesn't mean you have to ask people what they like, you can observe what they use, which is probably more accurate anyway.

Amazon, Ebay, Google and many others try new things all the time without lots of fanfare to see if they get used (i.e. market facts) to see if an idea is worthwhile.

Malcolm Gladwell in his Pop!Tech 2004 presentation (via ITConversations) talked about the Aeron chair and how people hated it at first, but gradually it became the best selling office chair of all time. His point was that people don't really know what they want. A common theme in software circles (the users don't really know what they need) there is some truth to it. But users (the market) will tell you if it is useful and you can save yourself a lot of time and effort if you collect some market facts.

Reference: A copyrighted story from SoftwareCEO written by Bob Weinstein Software product management: If you can't define it, you're doing a bad job at it and published by Pragmatic Marketing on productmarketing.com

From a copyrighted story at SoftwareCEO written by Bob Weinstein Software product management: If you can't define it, you're doing a bad job at it

Product managers' rule #1: The best product managers follow the Pragmatic Marketing maxim: Your opinion, while interesting, is irrelevant. Always use market facts to decide the best course of action.

Product managers' rule #2: Product management is a not a "natural" fit for everyone. A good product manager has a technical background with business savvy. Software engineers and programmers, for example, can make a smooth transition to product management because they're starting off with a strong technical background. But technical smarts alone won't cut it.

Product managers' rule #3: In "Crossing the Chasm," Geoff Moore says that product management is a senior, business-oriented role and typically fails because we staff it with junior, technically-oriented people.

Product managers' rule #4: Credibility comes from being able to manage the business of the product. Otherwise, product management gets relegated to a technical support role.

Product managers' rule #5: Product management is about delivering what the market needs. Good product managers spend more time in front of customers and potential customers; they spend less time on sales calls and in their corporate offices.

Product managers' rule #6: Product management is not necessarily about delivering what the customer asks for. The best products solve the customer's problems and no more. A product manager has to observe and understand what the customer needs in order to solve the problem, rather than building the features the customer requests. "The old guys at Home Depot do this well," says Johnson. "They don't ask you what you want to buy; they ask you to describe your project so that they can tell what you need to buy."

Product managers' rule #7: Mature companies value product management and enjoy shorter time to market. According to a survey Pragmatic Marketing conducted with softwareminds, companies that consider product-management business critical cut their time to market in half. This results from more focus on the product and less last-minute reaction to sales demands du jour.

Product managers' rule #8: Product management usually fails when organized in the development or engineering team. Technical managers do not consider product management a value-add to their teams and relegate them to project management and scheduling.

Product managers' rule #9: Similarly, product management fails in sales departments. Naturally, sales management considers product management a sales resource and allocates 110 percent of its time for supporting salespeople.

Product managers' rule #10: It seems counterintuitive, but product managers who spend a lot of time supporting salespeople find that they are not valued by their companies. Invariably, the product managers who have been laid off are the ones who are closer to sales.

From Patrick Cauldwell's Blog - Firefox and Sharepoint

Being a dedicated Firefox user, one of the few things that was still thwarting me was SharePoint.  We use SharePoint internally for a ton of stuff, and it was a drag to have to fall back to that other browser.  SharePoint pages look and work fine in Firefox, but I was having to reauthenticate on every single page, which really hindered my enjoyment of the experience.

I finally figured out how to get Firefox to do NTLM, which means I don’t have to deal with the authentication dialogs, thereby reducing my dependence on IE to one and only one application (Oddpost). 

It’s not at all obvious how to make it work, and it took me a few tries.  You have to go to your Firefox address bar and type about:config.  This will bring up the internal config editor, which allows you to set all kinds of properties that influence Firefox’s behavior.  Look for the key called network.automatic-ntlm-auth.trusted-uris.  Set that key’s value to a comma separated list of servers you want NTLM auth for.  So if your internal SharePoint sites are on servers called Larry and Mo, use “larry,mo”.  You can also add the same value to the key network.negotiate-auth.trusted-uris.  It’s unclear to me if that second one is required, but I set it, and everything works.  Now SharePoint works like a champ, and authenticates automatically.

I only had to set network.automatic-ntlm-auth.trusted-uris and it works like a charm, although the likelihood of finding out this information on your own is slim. Even if you know the config setting name Google only knows about 27 pages with a reference to it and several of those are non-english. A classic case of geekism, you can do it, but only if you know the secret incantation (reminds me of all those “magic” registry settings).