dev|sushi » asp.net

ASP.Net DropDownList annoyance

Adam — Fri, 19 Oct 2007 21:26:58 +0000

I recently ran into a problem with using the ASP.Net DropDownList for toggling the status of an element. The problem stems from how the ASP.Net page object works. In this article I present the problem and then show a solution that seems to work with some caveats.

My goal is to create a toggle for the status of a page. For example I have a report and it has the possible status of Open or Closed. The DropDownList contains only the opposite of the current status of the report so when the report is Open the DropDownList contains an empty item (no change) and Closed. Here is the code.





  Drop Down Annoyance


  
  Drop Down Annoyance
  Current Status: <%= Session("bool") %>
  Update to:

There are two problems at work here that cause a complete failure of the intended action. Firstly, during Page_Load the Click_Submit event has not yet fired so the Session variable still contains the old value of Open. The code then rebuilds the DropDownList based on the Session variable being unchanged. Secondly, doing the change of the DropDownList resets which option is selected loosing the users input.

We can fix both of these problems with one change to the code. Simply move the DropDownList change to the very last moment right before its declaration. Make sure to add all possible options to the declaration using ListItems, this is a must for it to work.

<%@ Page Language="VB" Debug="True" %>





  Drop Down Annoyance


  
  Drop Down Annoyance
  Current Status: <%= Session("bool") %>
  <%
    ' Setup drop down
    ddlItems.Items.Clear()
    ddlItems.Items.Add("")
    If Not Session("bool") = "Open" Then ddlItems.Items.Add("Open")
    If Not Session("bool") = "Closed" Then ddlItems.Items.Add("Closed")
  %>
  Update to:

What is going on here is that when ASP.Net creates the ddlItems object it loads it up with all the ListItems given in the declaration. These items are available throughout the code right up until the point where we Clear and then change the DropDownList. The Session variable has been changed by this time and so everything works out. One very important caveat of this method is that you must not use ddlItems.SelectedIndex since the number of options in the list changes, instead use ddlItems.SelectedValue.

Does anybody else have any novel solutions for working with DropDownList controls?

ASP.Net has 9 to 5 appeal

Adam — Mon, 23 Jul 2007 18:13:03 +0000

My first article on this blog was the first in the “Dynamic Control Creation” series. I wrote it because I was frustrated with how ASP.Net worked and wanted to share my discoveries/workarounds with other frustrated developers. After a period of time Google picked up my article and I started to receive a decent amount of traffic and some positive feedback. Here at work I use ASP.Net for a majority of my applications and so the blog has continued to focus on it primarily. An interesting thing that I’ve noticed is that site traffic has a very consistent pattern — which I attribute to my focus on ASP.Net. Above you see a graph — from Google Analytics — that shows daily traffic over the last five months. Each valley in the graph made up of the numbers for Saturday and Sunday which are consistently very small compared to the weekday traffic.

I’ve done a few inquiries and looked at a few other sites I have stats for and found that this isn’t all that common. When other sites match my pattern they have a high number of work time surfers coming to their site as I do. I use this loose research to conclude that ASP.Net is widely used in the workplace and much less common for personal/weekend projects. PHP blogs and websites have a very consistent amount of traffic on all days of the week as many weekend programmers surf for information.

What does this signify for ASP.Net? Very few people use it for fun for one thing. I certainly don’t when I don’t have to. In fact I am phasing it out at work slowly too, starting most new projects in PHP — which I’m not really a fan of either. Companies across the globe are buying into Microsoft server products and technologies and forcing it down their employees throats.

How do your traffic statistics look? What is your main theme/topic? Would you prefer to use a different programming language at work? Leave a comment, I’m very interested.

ASP.Net CheckBoxes should be able to have values

Adam — Mon, 16 Jul 2007 19:06:33 +0000

The ASP.Net CheckBox and CheckBoxList control don’t allow for the use of the full W3C HTML standard. For some reason Microsoft decided to implement a reduced functionality version that creates more work for the programmer. Come on Microsoft why can’t you follow even the simplest of standards? In this case it would make coding the .Net framework easier for you not to mention us!

The W3C HTML 4.01 specification specifically states for the value attribute to:

– Specify for radio buttons and checkboxes –
W3C HTML 4.01 Specification – INPUT Element

To me this quote reads as a strong recommendation to specify the value attribute rather than leave it up to the browsers default (generally "On"). Microsoft decided to not even allow the value attribute to be set. They went so far as to have a validation message built into Visual Studio that says:

Attribute ‘Value’ is not a valid attribute of element ‘CheckBox’

If you ignore the warning and run the page, the value attribute is missing. I have even tried circumventing the ASP.Net HTML-izer by adding value to the attributes collection with no success. Microsoft intentionally strips it, so I can only assume they have some reasoning behind this behavior and I imagine they will say something about security in defense.

There is one way to circumvent the behavior but it requires not using ASP.Net controls. Simply insert traditional input type=”checkbox” elements into your page and collect their values using Request.Form.

Sub Page_Load ()
  Dim value As String
  value = Request.Form("chkItem")
End Sub
…

CheckBox Item Text

I made a big deal out of this issue simply because to me it doesn’t make any sense. You can get around the issue and still use ASP.Net controls but it requires extra coding.

Sub Page_Load ()
  Dim value As String
  If chkItem.Checked Then
    value = "Some Value"
  Else
    value = "Some Other Value"
  End If
End Sub
…

When using the CheckBoxList control you will notice ASP.Net uses tables to layout the list. To keep it from doing this you simply need to add a few attributes. It should then use much more standards compliant code. I also show how to access which boxes are checked after postback in a CheckBoxList.

Sub Page_Load ()
  ' Find out which boxes were checked
  Dim value As String = ""
  For Each item As ListItem In cblTest.Items
    If item.Selected Then
      value &= item.Value
    End If
  Next
End Sub
…

As always let me know if you have any questions.

ASP.Net file download protection through authentication

Adam — Thu, 01 Feb 2007 00:04:28 +0000

Recently at work I needed to allow for the download of sensitive files over the web. Right away your mind should jump to the security issues involved with such an undertaking. How do you allow for download without compromising the sensitive data? There is a simple but flexible method that will work perfectly.

Source code for this project.

I found the method without any difficulty using Google. The site outlined how to create a secure file download page. While implementing this solution I ran into some issues so I figured I would present my improved version and expand on some helpful features of ASP.Net.

The first step is to create a page that will list files available to download. Each link simply gives different parameters to the download script specifying which file was selected.


  Select a file to download.
  
      
      ">file 1
      ">file 2
      ">file 3
      ">file 4

The Server.URLEncode function is necessary here to make sure the filename doesn’t get mangled. It replaces any special URL characters (such as : and \) with a % code. For example you have probably seen %20 in a few URLs before, it is a URL encoded space character. Now we will need to receive the file and verify the user is authenticated.

' Make sure the user should be able to download using
' your authentication scheme then send file
Sub Page_Load()
    ' Forms authentication check
    If Not User.Identity.IsAuthenticated Then
        ' redirect to login page
    End If
    ' URL key passing
    If CheckKey(Request.QueryString("key")) Then
        ' redirect to invalid key page
    End If
    ' Session key
    If CheckKey(Session("key")) Then
        ' redirect to invalid key page
    End If

    ' Make sure a file has been specified
    Dim filename As String = Request.QueryString("file")
    If String.IsNullOrEmpty(filename) Then
        ' redirect to no file specified page
    End If

    ' Make sure file exists
    If Not File.Exists(filename) Then
        ' redirect to file does not exist page
    End If

    ' Write file to browser
    Response.ContentType = "application/octet-stream"
    Response.AddHeader("Content-Disposition", "attachment; filename=""" & Path.GetFileName(filename) & """")
    Try
        Response.TransmitFile(filename)
    Catch ex As Exception
        ' Redirect to error opening file
    End Try
End Sub

Function CheckKey(ByVal key As String) As Boolean
    ' Validate user key
    Return True
End Function

I will not cover authentication here but the first step is to check to make sure the request to the download page is by a valid user. I have provided three skeletal checks in the code but you would use the one which matches your authentication scheme. After verifying the user is valid you may wish to check if that valid user is allowed to download this file based on some internal logic. (For example upload/download ratio sites, various user level sites, etc.) Once the user has been validated it is time to validate the request. The first check is to make sure a filename was passed. We then try to open that file and read in its contents. If at any point there is a problem we simply redirect the user to an error page.

Security Note: This method exposes the internal structure of your servers file system by passing it through the URL to the download page. It is not recommended to use this method AS IS in a production environment. A clever hacker could easily change the URL passed to the download script to point to a file in any directory on your server. Normally this isn’t an issue since the built in windows permissions should deny IIS/ASP.Net from accessing anything sensitive, however, I have seen incorrectly configured servers before.

' Write file to browser
Response.ContentType = "application/octet-stream"
Response.AddHeader("Content-Disposition", "attachment; filename=""" & Path.GetFileName(filename) & """")
Try
    Response.TransmitFile(filename)
Catch ex As Exception
    ' Redirect to error opening file
End Try

The final piece of code is the most important. The response object is the output we are going to send the users web browser. At this time we can change anything we like so as to masquerade our ASP.Net page as something else. For example you can set the response up as an image, use an image library and create dynamic thumbnails of images. Then your IMG src would be the .aspx page. In this case we want to send the user a file so we change the response to an octet-stream (binary data) and give the name of the attached file. The major bug that I fixed is to add the quotes to the response around the filename. This is very important since other wise browsers don’t get the full filename if it contains spaces. Additionally, some browsers have issues with this attachment method without the quotes.

Path.GetFileName is a very handy tool to grab the filename off the end of a path string. There are a whole set of static methods in the Path object that you can use in this fashion to take parts of the path or url that you wish without having to parse them yourself. Make sure to browse throught the MSDN page for the Path class (scroll down to the Public Members section).

One potential caveat is the downloading of very large files as described in this MSDN knowledge base article. However, a method is presented which should work. Another possible issue is with Response.TransmitFile itself, see this Microsoft fix.

If you are interested in some specific topic related to ASP.Net let me know and I’ll cover it in a future post. I am always interested to hear what types of things people are doing with .Net.

ASP.Net Dynamic Controls (Part 4)

Adam — Fri, 19 Jan 2007 06:49:49 +0000

I’ve had several people ask about redrawing a page that contains Dynamic Controls. The idea is that you have a page with a “Save” button that posts back but the page reloads exactly as it was. You can think of it like the “Apply” button in Windows but on a web page. The heart of the issue is what is the proper way to redisplay the data in the dynamic controls since they don’t have a viewstate.

In fact they do seem to have a viewstate but only if you regenerate the control exactly as it was before the post back. So if you create a checkbox with an ID of chkbox1 during Page_Load, after post back recreate it again during Page_Load with the same ID and it will repopulate from the viewstate. So you don’t need to use Request.Form to get the values and repopulate by hand which is a major plus.

<%@ Page Language="VB" %>







    Dynamic Control Test
    



    ASP.Net Dynamic Controls (Part 4) Demo
    
    
        
        
    
    
    
    
    Request.Form Contents

    <%  Dim str As String
        For Each str In Request.Form.AllKeys
            Response.Write("" & str & "
" & Request.Form(str) & "")
        Next
        %>

The sample code above shows off this working. There are a total of twelve checkboxes the first two are settings for the post back and the remainder are the dynamic controls. If you uncheck “Regenerate Dynamic Controls” and click save you will see that the checkboxes disappear but data remains in the Request.Form collection. Also if you check “Use Different IDs” it will randomly generate the IDs and the controls will not be repopulated, the ID must be the same for repopulation.

ASP.Net Dynamic Controls (Part 1) «
ASP.Net Dynamic Controls (Part 2) «
ASP.Net Dynamic Controls (Part 3) «

ASP.Net Dynamic Controls (Part 3)

Adam — Sat, 23 Dec 2006 10:10:42 +0000

I have received a few requests via email and in comments for more detail on how to get your data back after postback with dynamic controls. This evening I started to put together some code examples and mulled over the details of the article in my head. The first step was to re-read my previous two articles so I could get my bearings on where to start. Part 1 of this series is an initial outline of how to create dynamic controls and use Request.Form to collect the data after postback. Part 2 went into detail on how to figure out which button was clicked to cause postback using a JavaScript technique. In the middle of re-reading the second article I had an epiphany. There is a better way to do that! The proper method is standards compliant, accessible and is outlined in the W3C HTML specifications. So I will put the original article on hold and explain this technique.

What I didn’t realize when I wrote Part 2 of this series was that HTML forms have a built in way to recognize what button was clicked. Here is a relevant quote from the spec explaining it (poorly).

A successful control is “valid” for submission. Every successful control has its control name paired with its current value as part of the submitted form data set. A successful control must be defined within a FORM element and must have a control name.

So that is just a wordy way to say that form elements have their values returned in a name/value pair after the form is submitted. We have all seen the URL GET version (http://…../index.php?name=value&name2=value2) of this and the POST version is the same inside the closed POST package. So the only question is “What is a successful control really?” which requires more digging. Take a look for yourself there are many reasons. The one that is most interesting is “If a form contains more than one submit button, only the activated submit button is successful.” Perfect! So which ever button is clicked will have its name/value pair available to us on the other side of the submit. Lets take a look at an example:

You can see that the name/value pair after the question mark shows which you clicked. Since this does not require JavaScript it is a much more accessible solution to the problem. A wider number of users are now able to participate which takes us closer to our goal of creating a great website. The next step is to figure out how to utilize this information to overcome the chicken and egg problem.

Before going further I thought I would recap the chicken and egg problem so you know why we are doing this in the first place. The simplest example is a dynamic list of, for example, your friends on Facebook. When the page is generated we go to the database and collect all the people you have tagged as friends generating a list on the page. Each entry has some tools so you can interact with your friends, this included a delete button to remove them (perhaps if they Poke you rudely or defamate your wall). In order for the buttons to function we needed to generate the list in the Page_Load event. Now when the user pushes the delete button the page is redrawn. Event handlers fire after Page_Load so we have already added the deleted person back before they are to be deleted. In some cases it wouldn’t be a problem to simply remove them but it is wasted effort. We need a way of knowing about the click before we regenerate the list

Sub Page_Load()
  Dim i As Integer
  Dim btn As Button
  For i = 1 To 10
    btn = New Button
    btn.ID = "btn" & i
    btn.Text = "Button " & i
    phFun.Controls.Add(btn)
  Next

  For i = 1 To 10
    If Not String.IsNullOrEmpty(Request.Form("btn" & i)) Then
      … ' Perform action on the ith item
    End If
  Next
End Sub
…

You will notice that in the last example I don’t set the name or the value property of the button control. ASP.Net does the work behind the scenes, whatever you put for the ID will be the id and name attributes in the HTML and whatever you put in for Text will be the value attribute. I would like to hear from you, let me know if this works for you or if you need help getting it to fit the bill for your project. I’ll be back with the article I was initially going to write sometime next week and somewhere down the road I will make the jump to AJAX dynamic controls, stay tuned.

ASP.Net Dynamic Controls (Part 1) «
ASP.Net Dynamic Controls (Part 2) «
ASP.Net Dynamic Controls (Part 4) »

ASP.Net Regular Expressions

Adam — Tue, 28 Nov 2006 21:22:48 +0000

The RegularExpressionValidator control is an often overlooked tool for validation. A lot of people look at the validation expression and are puzzled at how to proceed. Most settle on the RequiredFieldValidator and hand coded filtering in the submit action. I hope to compile here a list of common expressions needed for web form validation so that your job is easier.

Why Regular Expressions

Forming a regular expression (sometimes shortened to RegEx) is not the easiest task since it requires a lot of “what if?” thinking about potential user input. There is also a large barrier to entry for the common programmer since they must first learn all of the special characters and how each of them works, then how they all work together when data is processed. It can take a very long time for a programmer to become proficient at creating the perfect expression. I have had a fair bit of experience at this but by no means would I call myself an expert.

When creating web forms we have the option to make them as flexible or as rigid as we want. On the rigid side we can require that the name is entered separately in first and last name boxes or that the phone number is entered in area code, exchange and number boxes, etc. This makes data collection and reporting very easy after the fact. On the flexible side the name could be one box, as well as the phone number, etc. I have seen both methods in action and the resulting data sets.

Data from the rigid side is very organized and clean and poses few issues when running queries after the fact. Data from the flexible side on the other hand is messy and requires much processing and special considerations to use. You might suspect from this that I think the rigid method is the best but you would be wrong. I am a big proponent of the flexible solution because I know how it can be done right and the result is a much friendlier user entry experience. All data collection issues can be solved with a combination of regular expressions and clean-up algorithms.

The RegEx List

Email Address
^[a-zA-Z0-9\-\._]+@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$

Phone Number (requires area code)
^\+?1?-?(\(\d{3}\)|\d{3})-?\d{3}-?\d{4}$

Phone Number (optional area code)
^\+?1?-?(\(\d{3}\)|\d{3}|)-?\d{3}-?\d{4}$

Curreny Amount (including dollars and cents)
^\$?\d+(\.\d{2})?$

Name (last, first)
^[a-zA-Z\-'\s]+,\s*[a-zA-Z\-'\.]+(\s+[a-zA-Z\-'\.]+)*$

Name (first, last)
^[a-zA-Z\-'\.]+(\s+[a-zA-Z\-'\.]+)+$

Postal Code
^[a-zA-Z][0-9][a-zA-Z]\s*[0-9][a-zA-Z][0-9]$

Zip Code
^\d{5}(\-?\d{4})?$

Clean-up Algorithms

These regular expressions allow for the user to enter most of the common syntax for a particular item which then allows you to write a clean-up function that changes the information into the format you want to store in the database. These functions would take the user input, check for the various cases (i.e. has area code brackets or not) and return it in the correct format. I recommend starting a module of these functions that each handle a different input type. After a short period of time you will find that you are able to throw together a rock solid flexible form in a few hours.

Feedback and expression requests are much appreciated. Let me know how these work out for you. Here are a few resources which I have found extremely useful: Regular Expressions in ASP.Net (MSDN) and the Regular Expression Tester.

Error Handling Correction

Adam — Wed, 11 Oct 2006 15:06:36 +0000

Today I realized a huge problem with the global.asax error handling method that I provided in my last entry. The problem is that if you ever run into compilation errors you are left completely in the dark as to what page it came from. You just have the date, logged in user and ip address which isn’t very helpful.

<%@ Import Namespace="System.Web" %>
<%@ Import Namespace="System.IO" %>

Now you will get the header and the page the error occurred on in all circumstances. Additionally there is less duplication since the form string is extremely long due to the viewstate and would be repeated in the event of an inner exception.

ASP.Net Error Logging

Adam — Fri, 06 Oct 2006 13:39:23 +0000

Like any good ASP.Net developer I have Scott Guthrie’s blog bookmarked in my GReader. Recently I was browsing through the archives and came across an entry about not using Debug=”True” in production applications. I have to admit that I am VERY guilty of this since pretty much all of my applications are production and are using Debug=”True”. The reason for this is simple, I am just me and I have to monitor/update all of these applications. I do as much testing as I can before sending it off to production and moving on to the next project but often once the users start working with it something bad happens. The ability to have the errors logged including the line number in the source code is invaluable when going back to an application to fix a bug after a length of time. However, in light of Scott’s points it stops now.

Current Error Methods

First let me outline how I look after error handling currently and then I will discuss alternatives and changes to become Debug=”False” compliant. There are a few different components to my current method but all are very simple and chances are most of you already have a much better system.

Try/Catch Blocks

I only use a Try/Catch block when I know exactly what might happen and how to recover from it. In fact I use them really only in three instances: Transactions, Date Conversion Checking and LDAP Authentication. The reason for this is because these cases all require (as far as I know) that you catch exceptions in order to handle a normal failure case. Lets take a quick look why. Transactions are for atomic database handling and allow you to cancel all partial queries if anything during a block of code causes an exception. So you must catch any exception so that you can rollback the transaction and keep the databases referential integrity. I have never been able to find an exception free way (save by doing a lot of coding) to check if a date is in the proper format to be put into a date object thus a catch is needed. Finally, the method to check user credentials with LDAP is to try connecting to it using those credentials. When you connect with invalid credentials .Net’s LDAP module raises an exception which you must catch to provide login failed information. Every other case where an exception might occur I program my way out of it by defensive checking and failing that let the exception propagate beyond the Page.

Application Error Handler

ASP.Net provides you the ability to override the application wide error handler with your own code so that you can log any errors that propagate up from your pages. You do this in the global.asax file that sits in your application directory beside your web.config file. Here is mine:

<%@ Import Namespace="System.Web" %>
<%@ Import Namespace="System.IO" %>

The gist of the code is to grab the error that causes us to be in the error handler and the current HTTP context and we’ll dump as much information as possible into errors.txt for debugging. With Debug=”True” this includes the line number that caused the exception. At this point all that is needed is to read the exception and find the bug. You can of course email the exception to yourself instead of logging it to a text file if you wish.

No more Debug=”True”

Now let us discuss what to do in the absence of Debug=”True”. All the above will still work exactly as before except that the line number is missing. There is no solution for this since the debug symbols that gave you the line number in the first place are now gone, compiled code has no line numbers.

Try/Catch Blocks

You can extend the use of your exception handling to include an error wrapper that collects the exceptions from a block of code and wraps it in another exception which then will be logged. This way you know exactly which block of code caused the error. Try not to make your Try/Catch blocks too small because the overhead might cause performance degradation.

Re-Enable Debug=”True”

If you have an exception happen that you can’t track down using the information provided then you can temporarily re-enable debug mode until you get the error again with the line number. This isn’t a very good solution since you are still using Debug=”True” in production.

Draw it out

Drawing out the relationships between the code and data is my method of choice for solving bugs I can’t find quickly. Narrow down where the error came from as best you can within the offending Page. It is almost a guarantee that the error was causes by user input so first write down all the inputs to the block of code on the left side of the page. Take a look at the controls that collect the inputs and figure out what the user can possibly enter. Next you have to consider the malicious case of page hijacking (which circumvents MaxLengths, hidden value reliability, JavaScript checks and updates, etc.). Are you dropping these inputs directly into a database that only allows a certain number of characters? Will an empty string cause problems? Take each input one at a time and walk it through its code path keeping in mind the potential inputs you calculated. Somewhere along one of the paths of one of the inputs is your exception.

Error handling is a very important part of programming and hopefully these tips will help you to be able to find and fix your applications bugs in a faster and more efficient way. I would really appreciate your thoughts or improvements on these methods.

Downlevel Forms Authentication

Adam — Mon, 25 Sep 2006 20:11:16 +0000

I ran into this issue a couple of weeks ago and have been itching to throw together an article about it. I initially suspected that it was a bug that was causing the problem but now I realize the truth. When you force a page into “Downlevel” mode using the ClientTarget property of the <%@ Page %> tag .Net doesn’t use cookies anymore. Out of the box forms authentication is done using session tracking via cookies and thus you are unable to log in.

One option is to not use “Downlevel” on the login page so that .Net will successfully give the user a cookie and they can proceed into your application. If you try this you will notice that users can not log out if you have the sign-out page using “Downlevel” too since .Net can’t expire the cookie. A work-around for this problem is to create a sign-out link instead of having the sign-out ability on every page. This way you can still use “Downlevel” in your application without blocking user sign-out. The following code is signout.aspx:

Thankfully even when your page is in “Downlevel” mode it can still access the Session variables based on the Session ID in the user cookie. So reading cookies is no problem in “Downlevel” mode just writing to them. The main reason for using “Downlevel” is to stop .Net from using client side validation so what are our options? Is there a different way to achieve this? How about changing how “Downlevel” functions?

Upon inspection all the browser configuration information exits in C:\WINDOWS\ Microsoft .NET\ Framework\ v2.0.xxxx\ CONFIG\ Browsers in various files. The “Downlevel” configuration is a clientTarget alias that points to “Generic Downlevel” which exists in the generic.browser file. I believe that if you change the cookie setting to “true” then restart IIS you will have cookies working in “Downlevel” mode. However, I did not test this since I don’t believe this is a very good option. The browser detection is a pretty complex hierarchy and it is best not to mess with it. Imagine that one day a user visits that actually maps to “Downlevel” on one of your other applications but then is given cookies what will happen? The browser will likely discard the cookie but the full repercussions are not simple to determine. There is more to “Downlevel” than cookies so from now on I won’t be recommending its use.

How about forcing server side validation? Absolutely! Although I could not find an application wide method you can set the EnableClientScript property of each validator control to “false” which will force the control into server-side validation mode.

What to take away from this article? Well the issue of using ClientTarget=”Downlevel” is more complex than simply causing all controls to use server-side validation in one statement so it is best not to. Take the extra time to set the EnableClientScript=”false” for each validator and save yourself the issues involved with the ClientTarget method.