Validating Input

You might have noticed that CHttpRequestParams derives from CValidateObject . There are two categories of methods that CHttpRequestParams inherits from: one category is a set of overloaded Validate methods, and the other category is a set of overloaded Exchange methods. These two sets of methods address the short-comings that we listed in the previous section. The set of Validate methods allows you to determine if a specific input exists, and optionally whether that input fits into certain constraints, such as a minimum or maximum length. You ll examine this set of methods in detail in this section, and then you ll look at the Exchange methods in the next section. Consider the example in Listing 6-4.

Listing 6.4: Validating Input in ValidateAndExchange

 1  HTTP_CODE ValidateAndExchange()  2  {  3    const CHttpRequestParams *requestParams(NULL);  4  5    // determine what method our form is using  6    if (m_HttpRequest.GetMethod() == HttpRequest::HTTP_METHOD::HTTP_METHOD_POST)  7    {  8      // using POST  9      requestParams = &(this->m_HttpRequest.GetFormVars());  10   }  11   else  12   {  13      // using GET  14      requestParams = &(this->m_HttpRequest.GetQueryParams());  15   }  16  17  LPCSTR value;  18  DWORD result = requestParams->Validate("fruit", &value, 5, 19, NULL);  19  20  switch(result)  21  {  22    case VALIDATION_S_OK:  23    {  24      m_HttpResponse << "Ok, you chose a " << value;  25      break;  26    }  27    case VALIDATION_E_LENGTHMIN:  28    {  29      m_HttpResponse << "Name of the fruit was not long enough.";  30      break;  31    }  32    case VALIDATION_E_LENGTHMAX:  33    {  34      m_HttpResponse << "Name of the fruit was too long";  35      break;  36    }  37    case VALIDATION_S_EMPTY:  38    {  39      m_HttpResponse << "No fruit was selected";  40      break;  41    }  42    case VALIDATION_E_PARAMNOTFOUND:  43    {  44      m_HttpResponse << "input value was not found";  45      break;  46    }  47    case VALIDATION_E_INVALIDPARAM:  48    {  49      m_HttpResponse << "Invalid selection";  50      break;  51    }  52    case VALIDATION_E_FAIL:  53    {  54      m_HttpResponse << "unspecified error";  55      break;  56    }  57  }  58  59  return HTTP_SUCCESS;  60  } 

 

Let s look at this example line-by-line :

• Lines 1 through 16: This is the same code that you ve seen in previous examples to get a CHttpRequestParams object independent of whether you re using POST or GET .

• Line 18: You re trying to validate that the input parameter named fruit exists, and that it s between five and nine characters in length. This type of validation can help make your application more secure and robust. It helps you easily avoid buffer overruns by validating the length of your input before processing it. The last parameter is the validation context. You can ignore that for now and pass NULL ; you ll look at validation contexts later on in this chapter.

• Lines 20 through 56: Validate will return a result as a DWORD . This value can be any of the following:

  • VALIDATION_S_OK : The named value was found and could be converted successfully.

  • VALIDATION_S_EMPTY : The name was present, but its value was empty.

  • VALIDATION_E_PARAMNOTFOUND : The named value was not found.

  • VALIDATION_E_INVALIDPARAM : The name specified was not found.

  • VALIDATION_E_FAIL : An unspecified error occurred.

  • VALIDATION_E_LENGTHMAX : The value exceeded the maximum length.

  • VALIDATION_E_LENGTHMIN : The value was less than the minimum length.

The validation features of ATL Server make it trivial to validate your input against a set of specified constraints. Doing this will add both robustness and security to your application. A lot of thought was put into designing this validation because this is an area in which many Web applications are prone to error.

There are also two overloads of Validate that do some basic data type conversion for you. You can validate your input for length as you saw previously and have the value returned as a CString . You can also validate your input for minimum and maximum values, and have the value returned as a double . We don t cover specific examples of these methods, as they re very similar to the example of Validate that we just presented.

Validation addresses the first shortcoming that we identified when you started looking at how to access your user s input. With validation, you can ensure that your input exists and conforms to a set of constraints that you ve specified. We also touched on the fact that validation does some simple data type conversion for you. In the next section we expand on that idea and look at the Exchange functionality in ATL Server, which has extensive support for data type conversion.