Users have accessed this code article 6427 times.

Visual WebGUI provides a LogonForm class and the Session.IsLoggedOn property to control access to a VWG application.  When Session.IsLoggedOn is false VWG automatically displays the logon form and blocks access to other forms until IsLoggedOn is set to true.

IsLoggedOn is essentially a global authorization switch.  It is left to the developer to implement user and request authentication plus set the IsLoggedOn switch appropriately.  Examples of this feature, to-date, have not address how to perform the authentication in a secure manor that prevents session hijacking and spoofing.

ASP.NET 2.0 and above provides a robust infrastructure for storing user accounts, authenticating requests, performing role based authorization, and profile personalization.  Microsoft's "out of the box" infrastructure specifically addresses hijacking issues, and when combined with SSL, is a very secure solution.  Even if you can't run your entire site in SSL the authentication approach Microsoft implemented is still one the best approaches available.

The trade-offs between security, performance, and configuration of this ASP.NET infrastructure is well documented so lets focus on how to integrate these features into a VWG application.  The sample application provided demonstrates the five steps that allow a typical VWG application to benefit from this infrastructure:

1)  Write a Module to handle the PostAquireRequestState event which sets VWG's Session.IsLoggedOn to false when HttpContext.User.Identity.IsAuthenticated is false.

2)  Write a logout.aspx page that abandons the session, removes the ASP.NET_SessionId cookie, calls FormsAuthentication.SignOut(), and then redirects to the application's main VWG form.

3)  Modify the form derived from VWG's LogonForm to call a few Membership and FormsAuthentication methods and set VWG's Session.IsLoggedOn property correctly.

4)  Modify web.config to add the module from step 1 and configure ASP.NET's Forms Authentication, Membership, and Role infrastructure.  The only unusual trick is to configure Forms Authentication so that the loginUrl attribute is set to "logout.aspx" and the defaultURL attribute is set to the URL of application's main VWG form.  It feels odd to call the logout page to login but the logout page takes care of removing the Session, performing some anti-spoofing logic, and redirecting to the main VWG form; VWG auto-magically detects that IsLoggedOn is false and displays the logon form.

5)  Add calls to VWG's Context.Redirect(FormsAuthentication.LoginUrl) as desired to sign out the user.  This sends the user through the logout.aspx page and they end up at the logon form.

The sample application demonstrates how to configure ASP.NET's Health Monitoring to automatically log specific events.  All failed logins are logged, along with unhandled exceptions, plus a hand full of other interesting events.  The sample application data bindings a grid to the events, which are stored in SQL Server, to display what is logged.

The sample application also implements a global exception handler that subscribes to the Application_ThreadException event.  All unhandled exceptions end up in this global exception handler where the exception is logged and a friendly error is displayed to the user in a MessageBox.

The only twist to the global exception handler is that the logon form must register the global exception handler in the form's constructor then unregister it before the main form is displayed.  The main form must then register the global exception handler in its constructor.  This is a work-around because VWG appears to lack the concept of a "Main" method that is executed when the application instance is created.  If such a "Main" method existed it would be the appropriate place to register the global exception handler instead of having to register it in multiple places.

Finally there is a test.aspx page that proves VWG is indeed interopting with ASP.NET's security infrastructure.  The aspx page is only accessible when the user is signed into the VWG application.

It is also important to note that every request for an extension registered with ASP.NET is authenticated.  The default web.config that is included in a new VWG application dynamically generates resources using the same extension it uses for forms.  Make sure to change the StaticResource's Mode attribute to "On" before deploying your VWG application to production.  This will significantly reduce the number of requests that ASP.NET handles and hence authenticates.  No reason to authenticate requests for images, right?

Hopefully you can use the sample code to jump start your next secure application.

Download Code

Note: Codes are submitted as a .zip file to shorten your download time. After downloading it, you will need a program like Winzip to decompress it.

Terms of Agreement:
By using this code, you agree to the following terms...

1. You may use this code in your own programs (and may compile it into a program and distribute it in compiled format for languages that allow it) freely and with no charge.
2. You MAY NOT redistribute this code (for example to a web site) without written permission from the original author. Failure to do so is a violation of copyright laws.
3. You may link to this code from another website, but ONLY if it is not wrapped in a frame.
4. You will abide by any additional copyright restrictions which the author may have placed in the code or code's description.