irob's blog. : DNN

"Improving the Secured File UX" Part Two

irobinson — Sun, 07 Dec 2008 04:43:00 GMT

In Improving the Secured File Download UX for Unauthenticated Users I elaborated on a ~~workaround~~ hack to display a friendly error message and redirect to the login page when trying to access a file that had been through DotNetNuke's file ticket system.

If you're in a situation where that solution makes sense for you - great. But what about future releases of the application? Should this functionality exist within the framework itself? Is it too trivial? Does it make sense for everyone that uses the framework so much so that it should be a part of it?

To find out, I put the issue in DotNetNuke's Gemini.

I suggest that when you encounter a workaround/hack/enhancement such as this:

Don't just fix it for now
These "fringe areas" are one of the places where the "community at large" can be of most help. Let the core team focus on the big stuff.
So...put it in Gemini!
And, ideally, try to give the core team a head start.

So, in an effort to follow the above path, I cracked open my handy DotNetNuke source code and made a few changes.

update: I'm providing the following information for reference only, I really don't think you should make this change to your DNN application. My intention is just to remind you that the core code is there, we can easily make changes, test them out, and suggest to the DotNetNuke team that they incorporate those changes into the application.

Background

When the user requests the file, the LinkClick.aspx "page" is requested. (e.g. "http://localhost/DotNetNuke_2/LinkClick.aspx?fileticket=XKDsP6pHvtQ=&tabid=36&mid=410"). This really isn't a page, but is a handler registered in the application's web.config.

The actual class that handles the file request is called "FileServerHandler" and is found in Library\Components\FileSystem\FileServerHandler.vb in version 4.9 and \Library\Services\FileSystem\FileServerHandler.vb in DotNetNuke 5.0 RC2.

While some slight refactoring has been done to this class between 4.9 and 5.0, the portion we're concerned with has not changed:

' serve the file
If TabId = Null.NullInteger Then
    If Not FileSystemUtils.DownloadFile(_portalSettings.PortalId, Integer.Parse(UrlUtils.GetParameterValue(URL)), blnClientCache, blnForceDownload) Then
        context.Response.Write(Services.Localization.Localization.GetString("FilePermission.Error"))
    End If
Else
    If Not FileSystemUtils.DownloadFile(_portalSettings, Integer.Parse(UrlUtils.GetParameterValue(URL)), blnClientCache, blnForceDownload) Then
        context.Response.Write(Services.Localization.Localization.GetString("FilePermission.Error"))
    End If
End If

The above code is responsible for the original behavior of showing the localized file permission error message.

Goals for Improvement

If the user is not able to download the file:

If they are not logged in, let's take them to the current portal's login URL with a return URL for the file ticket.
If they are logged in, display the localized FilePermission.Error message, as usual.

Adding a Utility Method

First, let's add a method to help us get the current portal's login URL:

Private Function GetLoginUrl(ByVal portalSettings As PortalSettings, ByVal request As HttpRequest) As String
    If Not portalSettings Is Nothing AndAlso Not request Is Nothing Then
        Dim tabId As Integer = portalSettings.ActiveTab.TabID
        Dim controlKey As String = "Login"
        If Not Null.IsNull(portalSettings.LoginTabId) AndAlso String.IsNullOrEmpty(request.QueryString("override")) Then
            controlKey = String.Empty
            tabId = portalSettings.LoginTabId
        ElseIf Not Null.IsNull(portalSettings.HomeTabId) Then
            tabId = portalSettings.HomeTabId
        End If
        Return DotNetNuke.Common.Globals.NavigateURL(tabId, controlKey)
    Else
        Throw New ArgumentNullException(If(portalSettings Is Nothing, "portalSettings", "request"))
    End If
End Function

This method is intended to yield the correct login page whether a custom one is specified or not. It could potentially use the current tab, or the home tab as well. Just playing it safe.

Adding the core enhancement

Now, we need to figure out whether or not the user is logged in, and perform one of two actions. Either redirect them to the login page, or let them know that they don't have sufficient privileges to view the file.

Private Sub RedirectToLoginOrDisplayErrorMessage(ByVal context As HttpContext, ByVal _portalSettings As PortalSettings)
    If (context.Request.IsAuthenticated = False) Then
        Dim loginPage As String = GetLoginUrl(_portalSettings, context.Request)
        Dim returnUrl As String = HttpUtility.UrlEncode(HttpContext.Current.Request.Url.PathAndQuery)
        context.Response.Redirect(loginPage + "?returnurl=" + returnUrl)
    Else
        context.Response.Write(Services.Localization.Localization.GetString("FilePermission.Error"))
    End If
End Sub

Wiring it Up

Now, without changing the original code much, we can replace a couple lines of code, set a few break points, and try this thing out.

' serve the file
If TabId = Null.NullInteger Then
    If Not FileSystemUtils.DownloadFile(_portalSettings.PortalId, Integer.Parse(UrlUtils.GetParameterValue(URL)), blnClientCache, blnForceDownload) Then
        RedirectToLoginOrDisplayErrorMessage(context, _portalSettings)
    End If
Else
    If Not FileSystemUtils.DownloadFile(_portalSettings, Integer.Parse(UrlUtils.GetParameterValue(URL)), blnClientCache, blnForceDownload) Then
        RedirectToLoginOrDisplayErrorMessage(context, _portalSettings)
    End If
End If

Summary

Mission accomplished. Now to see if it gets picked up anywhere along the way. Let me know what you think of this enhancement or the process in general. Also, I did enjoy picking apart this one trivial thing, so if you have any suggestions for future experiments, please let me know.

Signs your DNN Module Development skills could use some sharpening

irobinson — Mon, 03 Nov 2008 23:32:00 GMT

Your latest DNN module utilizes in-line CSS like it was going out of style.
You frequently need to release new versions due to changes that consist solely of updates to hard coded strings in your code-behind.
Every time you implement your modules as part of a new solution, you spend the first few days just getting them to display correctly in the new skin
You FTP into the production DNN site to upgrade your module.
You spend more than 30 seconds packaging a new version of your module
When you get a SQL script from source control you open up your favorite file comparison utility to see what’s changed so that you can run only those changes.
You’ve been curious, for the last two years, about how to use the DNN UrlControl, but you never have the source readily available, so you still don’t know.
The last time you upgraded your production environment you were up until 4AM trying to piece together outdated versions of your database.
When creating your latest DNN module, you opened up the first DNN module you ever created to grab that same piece of code that you always grab when creating a new module.

Creating DotNetNuke Modules using a Web Application Project (WAP)

irobinson — Wed, 15 Oct 2008 17:03:47 GMT

When creating a DNN module, you have the option to choose from the web site project (WSP), or a web application project (WAP). I prefer the web application project approach, and I'll explain it for developers who are new to module development, or unfamiliar with the WAP approach for developing modules.

There are two major reasons why I feel WAP is generally better than WSP for DNN module development.

1. Conciseness - the project contains only your module's code, nothing more. Separating your module from the DNN web site itself in Visual Studio really helps with performance and maintainability.

2. Compiled - I like having the code compiled into an assembly. This makes it easier for me to build a module package and distribute. I like to use a NAnt script for each module that creates the packages for me. The WAP project style lends itself to this approach.

If you'd like to give it a try - here are the steps involved.

Create a new WAP project, or alternatively, use a C# DNN Module WAP Template
Place the root of the project in the DesktopModules directory of your DNN development web site's file system (e.g. ..\DesktopModules\MyModule\)
Set the project to build the assembly and place it in the "bin" directory of the DNN web site
Set the project to launch your DNN web site (e.g. http://localhost/DotNetNuke) when you F5/run.
In order for Visual Studio to know about your development web site, make sure to set your project to use your IIS server, and set the Override application root URL to the root of your web site. When you do this, Visual Studio knows that paths starting with "~" are really pointing to the DNN web site, and not just to your project. This makes it possible to include controls from within the DNN site, like the DNN Label or URL control.

After your module is set up, you can import it (by importing the .dnn manifest file) into your development site, and run any database scripts that the module may have. Your module is now fully integrated into your DNN site.

TIP: to debug the module, you may find it helpful to "attach to process" in Visual Studio while you already have the web site running in a browser. This saves you from having to launch the web site multiple times.