Creating a Stateful Web Service

Creating a Stateful Web Service

One of the problems in web development is the server-client model, or specifically the thin-client model. Where thin client refers to the web browser being used to access your application. This style of client-server model is a stateless model, meaning that no information (state) can be retained across multiple requests to the server.

This is essentially how the web functions, and it creates several inconveniences in development due to the workarounds that can be implemented. Most developers are familiar with the session object, which is a uniform concept in web applications that can be found in most development languages. Session variables allow your application to become stateful because you can store information for each individual user and persist that information across multiple requests.

Note: This tutorial requires Visual Studio.NET. Both VB.NET and C# code will be provided for both the Web service application as well as the consumer ASP.NET application

Encrypted QueryStrings in .NET

Encrypted QueryStrings in .NET

When ASP.NET first arrived to the development community a few years back it was clear that one of the primary goals of the technology was to simply front-end development patterns. Many of the troublesome kinks that made classic ASP development very cumbersome had been addressed and pre-built into ASP.NET, allowing the developer to focus on functionality rather than finding solutions to the limits of the technology.

One of these new patterns is now widely known as the post-back concept, whereby forms no longer post themselves to other pages, but rather post to themselves, containing all the form information through the new ASP.NET control objects. You no longer had to “receive” form posts and process the data.

There are certain situations however, where posting or sending information to the same page that originated the data is just not an option. So there is still a need to use either querystrings, or post form data to another page. A good example is a page with overloaded functionality, and the querystring can tell the page which “context” it should run in, thus rendering dynamic content based on the querystring.

Another example could be a page which renders a certain object from your database, such as a document, or an image. The querystring can tell the page which document to fetch and render the result on the page.

Whatever the situation may be, there are times when the querystring information should remain private, or at least inconspicuous. As you’re well aware querystring data by default is clearly visible and decipherable by the naked eye. Taking the document example, a user could simply append: documentid=number to the page and render any document they wish, possibly breaching security or permissions in your application.

In this tutorial we will explore a basic encryption/decryption pattern which will allow your querystring data to remain encoded, and unreadable. Though not recommended for mission critical enterprise applications this basic pattern will alleviate the most common problems associated with unencrypted data.

Multi-Level Forms Authentication with Dreamweaver and ASP.NET: Roles Logins

Authenticating users is a common task—one with which all web application developers should be familiar. In Classic ASP, Dreamweaver developers have long had the convenience of the built-in Macromedia Server Behaviours for implementing forms based authentication and authorization schemes. Needed security features such as Login User or Login User with Levels (Roles in Windows parlance) and Create New User are a simple point and click away.  When the Dreamweaver team implemented support for ASP.NET these familiar—and easy to use, server behaviours somehow never made it into the package. While many have wondered why this important functionality seems to have been left out, I wondered what it would take to implement it. And that leads to numerous and interesting questions.

But first before you get too involved, let’s see if you’re ready. This tutorial makes some assumptions about your skill level--that is, this tutorial is intended for intermediate users. If you’ve never configured a new site in Dreamweaver, never configured a database connection string, or never used the Dreamweaver database connectivity tools, this tutorial is probably not for you as you’ll need to be familiar with these concepts and techniques. If you have done these things but have very little or no experience hand coding, writing SQL statements, using the Dreamweaver advanced Dataset Dialog, don’t worry we’re doing this together and I’ll to do my part to bring you along.  

Data Driven Email Templates

It can easily be argued that sending email notifications is a part of almost any Web application. Whether you’re developing small 2-tier apps to full n-tier enterprise apps you are more than likely going to wind up with the requirement to interact with customers/clients/users via email notifications.

There is literally and endless supply of email components available on the net today. Most of them are free to download and distribute, while other more advanced components can be purchased for a reasonable price. For me personally, I would rather implement my own functionality majority of the time rather than reading through support documentation and code samples trying to figure out how to make 3^rd party components function with my existing application.

Tip: If you do not have Microsoft Access installed on your machine you can download the .mdb file for this tutorial and setup your database connection in Dreamweaver to point to this file.