Several of the earlier installments in this article series examined how to apply authorization rules in order to prohibit particular users, roles, or classes of users from accessing particular resources. For instance, Part 2 showed how to define URL-based authorization rules in web.config for roles. With just a bit of XML markup, it is possible to block particular users or roles from visiting certain web pages. Just installments also looked at using the LoginView control, which displays different markup based on whether the user is authenticated or not (and can also be used to display different markup based on the currently logged in user's role). There are also programmatic techniques you can use to determine the identity of the currently logged on user and what roles she belongs to.

The URL-based authorization, LoginView control, and programmatic techniques can be used in tandem to ensure that a user does not visit a page or perform some operation if she is not authorized. But what if you forget to implement one of these safeguards? For example, imagine that you have a web page that includes a button that, when clicked, perform some task that is only intended for administrators. You could put this button in a LoginView control or you could use programmatic techniques to ensure that only users in the appropriate role (say, Admin) saw the button. But what if sometime later you, or another developer, removed this check by accident? The net result would be that any user visiting the page could perform the administrator-only operation! Whoops!

To reduce the likelihood of such security mishaps, the .NET Framework includes capabilities for declaratively asserting permissions (via attributes) on methods and classes. In a nutshell, you can add such attributes to ASP.NET pages, their code-behind classes, and your business logic and data access layers. With these attributes in place, your visitors will be barred from performing unauthorized actions, regardless of whether there are any security holes in the user interface. Read on to learn more!
Read More >

Last week's article, Using a Dynamic IN Clause, showed how to display detail records for a set of user-selected master records. This entailed creating a User Defined Function (UDF) in the database that would translate a comma-delimited string into tabular data that could then be parsed by SQL's IN keyword. Following that, the user interface was created using a CheckBoxList to enumerate the master records and a GridView to display the details records for the checked master records. The demo available at the end of this article includes the exercise created in last week's article, which uses the Northwind database and the Categories and Products tables as the master and details records, respectively.

Most users who view a master/details report are interested in a particular subset of master records. Such users will quickly become frustrated when visiting the master/details report because each time they visit they have to tediously check each master record checkbox of interest before seeing the results. This frustration is heightened when there are many master records that need to be selected. The user experience can be greatly improved by allowing a user to save their default master record choices and then having the master/details report's master records pre-selected accordingly.

This article takes the master/detail report demo created in the Using a Dynamic IN Clause article and extends it so that the report's master records are pre-selected based on the user's preferences. Read on to learn more!
Read More >

The master/detail report pattern is used to display information in two database tables that share a one-to-many relationship. Typically the user is shown a list of the master records and can pick one to view the corresponding detail records. Consider the Northwind database that models product information using two tables, Categories and Products, where each product is assigned to precisely one category. Categories represent the master records and products the detail records. In a master/detail report, the user would choose a category to see the products that belong to it.

Imagine, however, that instead of letting the user pick one category we needed to let them pick any number of categories and then show the products that belonged to any of those selected categories. SQL includes an IN keyword that can be used to return detail records within a set of master records. Unfortunately, there are challenges using the IN keyword with values supplied at runtime. The good news is that with a little bit of work, we can overcome these limitations.

This article is the first in a two-part series that looks at displaying detail records from a set of user-selected master records. This first part looks at extending the IN keyword functionality to allow for the parameters in the IN keyword to be supplied at runtime. The second part shows how to save what master records the user wants to search on by default and how to have these selections automatically applied when visiting the report page. Read on to learn more!
Read More >

While reading through some of Jeff Atwood's old blog entries, I stumbled across this gem: The Danger of Naivete. In it, Jeff discussed the pitfalls the can befall a programmer who implements a naive algorithm and calls it a day. Consider an algorithm to randomly reorder an array. If you have a collection of items to reorder, the naive approach is to enumerate each element and swap its position with an element in some other randomly-selected position. However, such an algorithm (as we discuss in this article), does not have an even distribution of results - certain permutations are more likely than others when starting from a set point.

Jeff's blog entry caught my attention because of a past article I wrote here on 4Guys, Randomly Reordering an Array. That article, written back in 2000, showed various techniques for reordering an array in classic ASP using VBScript. And, wouldn't you know it, the first technique uses the exact same naive algorithm Jeff warns about in his blog post! Oops! (I've since updated the old article.)

After learning of the problems with the naive algorithm I decided to spend some time exploring approaches that produce valid distributions. This article shows why the naive algorithm produces less than ideal results and includes code for two alternative solutions. Read on to learn more!
Read More >

Many websites that support user account allow anyone to create a new account, but require new users to undergo some form of verification before their account is activated. A common approach is to send an email to the newly created user with a link that, when visited, activates their account. This approach ensures that the email address entered by the user is valid (since it is sent to that user's email address). This workflow not only ensures the valid data entry, but also helps deter automated spam bots and abusive users.

In past installments of this article series we've seen how to use the CreateUserWizard control to allow users to create new accounts. By default, the user accounts created by the CreateUserWizard control are activated; new users can login immediately and start interacting with the site. This default behavior can be customized, however, so that new accounts are disabled. A disabled user cannot log into the site; therefore, there needs to be some manner by which a newly created user can have her account enabled.

There are many ways by which an account may be activated. You could have each account manually verified by an administrative user. If your site requires users to pay some sort of monthly fee or annual due, you could have the account approved once the payment was successfully processed. As aforementioned, one very common approach is to require the user to visit a link sent to the email address they entered when logging on. This article explores this latter technique. Read on to learn more!
Read More >

Microsoft's ASP.NET AJAX framework ships with a mere five Web controls: the ScriptManager and ScriptManagerProxy; the UpdatePanel; the UpdateProgress; and the Timer. Previous installments in this article series have examined all but one control, the Timer. As we've seen from the first installment, all web pages that use the framework must have precisely one ScriptManager control on the page. The UpdatePanel control defines a region on the screen whose content is updated via partial page postbacks, and the UpdateProgress control provides visual feedback during the execution of a partial page postback. The Timer control, which is the focus of this installment, raises a postback every time a specified number of milliseconds has elapsed.

The Timer control is useful in scenarios where a portion of the screen needs to be updated every so often. For example, many financial websites display stock quotes that are refreshed periodically. Prior to AJAX, refreshing the stock quote entailed reloading the entire document, which would result in a screen flash and necessitate the browser re-downloading the entire content of the page (even though the only change that has occurred is the stock quote). Using AJAX techniques we can have the page asynchronously communicate with the server to get the latest quote every n millisconds and seamlessly update the quote on screen. The Timer control, along with the UpdatePanel, make implementing such scenarios a breeze.

This article shows how to use the Timer control to trigger a partial page postback every five seconds. It also shows how to start and stop the Timer through both server-side and client-side code. Read on to learn more!
Read More >

When using Microsoft's ASP.NET AJAX framework and an UpdatePanel whose ChildrenAsTriggers is set to True (the default), anytime a user interface element within the UpdatePanel would normally cause a full page postback, a partial page postback is performed instead. For example, clicking a Button Web control or selecting a different item from a DropDownList control whose AutoPostBack property is set to True normally causes a full page postback, but if these controls are within an UpdatePanel, a partial page postback occurs instead. But what happens if a partial page postback is taking a while to complete and the user triggers the partial page postback again? Or what if during this lull she clicks some other Button in the same UpdatePanel, thereby causing a second partial page postback to ensue?

If a partial page postback is made from the same UpdatePanel while a partial page postback is ongoing, the first partial page postback is aborted and the second postback commences. Aborting a partial page postback simply means that the ASP.NET AJAX framework on the browser no long listens for a response back from the server for that request. It does not stop processing on the server, or rollback any state changes that may have occurred on the server. Consequently, if on a partial page postback you are inserting records into a database or making some other state change, if a user clicks a Button in an UpdatePanel to instigate a partial page postback, but then clicks the same Button again while the partial page postback is still ongoing, there will be two duplicate records inserted in the database.

There are a couple of ways to prevent the user from resubmitting a partial page postback while it's still ongoing. The most effective way, in my opinion, is to "freeze" the frame by overlaying the screen with a <div> element. (See the final demo in the article, Providing Visual Feedback with the UpdateProgress Control.) Another option is to disable the user interface element that triggered the postback during the partial page postback lifecycle. This prevents the user from resubmitting the partial page postback. Read on to learn more!
Read More >