When working on binding a SQLDataSource to a GridView control one goes through a series of steps in the Visual Studio DataSource configuration wizard. A step that I often use but do not look much into is that of associating a parameter source with the parameters being passed to the database.
This step is quite important and ends up saving me a lot of time when I’m hooking up a WebForm that I have built to a datasource, but although I regularly use a few of the parameter sources, for a long time I was not familiar with what some of the parameter source options even do.
For instance, the Form parameter source really didn’t seem very clear to me when I first looked at it and it took a bit of looking into to find out what it does.
If you are not sure what I’m talking about, here is a screen-shot of the Visual Studio wizard where I am selecting a Form parameter source:
After looking around on Google.com for more information I found a bit more information about what exactly the Form parameter binding option does. Basically it tells your ASP.NET DataSource control to populate a specific parameter with name/value information that has been passed to the WebForm via a traditional HTTP POST command. So, this binds a DataSource parameter to a name/value collection that is passed to the page as part of the post data that is sent from a HTML page as part of its submit command.
For example if you have an HTML form with an <input type=”hidden” /> field that has data you would like to save, you can ask ASP.NET to automatically bind this field to your DataSource. Below is a screen-capture of what the Visual Studio wizard looks like once you have entered the Form connection information to bind to a parameter in your SQLDataSource:
As one begins adding the name of the Form Field value into the Visual Studio wizard, one can see in the left-most pane that Visual Studio is taking the name being entered and is transforming it into a Request.Form(“name1”) server request. This means that you can retrieve the values for HTML form elements passed as part of the request body, but this will not work to get values passed directly to the page through a HTTP GET syntax. So for example, you cannot bind your DataScource parameter to a name/value pair that is passed via a URL parameter in the form of: http://yoursite.com/yourPage.aspx?name1=value1&name2=value2 .
As part of filling out the parameters wizard don’t forget to set a default parameter value. Your ASP.NET WebForm will first attempt to retrieve the passed in Form parameter, but if this is not found ASP.NET will use the default parameter value that you supplied in the Visual Studio wizard, so this is an important option to provide when connecting your SQLDataSource parameters to a Form’s POST event in order to avoid unnecessary SQL Errors.
When using the Form parameter option, remember that an inherent limitation of using Request.Form with the HTTP POST command is that you need to limit the data posted to under 100KB in size. This is certainly better than the 2-8KB maximum (dependant on the browser version) of an HTTP GET Request.
Also noteworthy is that if you are binding to a form element that permits multiple selections (such as a multiple selection <input type=”select” multiple=multiple /> list, then instead of a single value you could be passed a comma-separated list of values. So directly binding your DataSource would not be useful and you should consider parsing the input into separate values first.
For page security purposes using HTTP POST rather than HTTP GET is a good thing but is still not secure enough. Although your URL cannot be directly tampered with, you are still open to attacks against your code from spoofed or altered Form POST information. This is especially dangerous if you allow the binding to directly point to your database.
So if you are binding from a trusted location binding to a form element, this form of binding can be useful, but if you are coding for a Web site with unauthenticated users, this is a dangerous option.
Binding to an unprotected value that could be doctored by a malicious user so I would suggest using another vehicle for passing information. If you have to pass information between two different pages then I would suggest using Session parameters, but overall if you can re-write your code to use the same page, then I absolutely recommend using ViewState. ViewState is an especially good option for security since it can be encrypted to avoid tampering, which in my books is a big plus!
I hope that this overview of using the Form option when defining your DataSource parameters has been useful. When used in the right circumstances it can be a handy tool that can help save on development time and effort.