irob's blog.

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.

DotNetNuke has extensive security features. One of which is enforcing role based permissions when accessing files. The general workflow is to say that "Registered Users" get to see a particular file, you then create a link to that file using DNN, and as a matter of course, the roles are enforced. This uses what's known as a file ticket to request the file, so that it is not linked to directly.

This post is overdue. I wanted to use this image in my slide deck for a presentation I gave last month at the Bloomington, IL .NET user group, but...it really detracts from the look & feel of the presentation as a whole makes my eyes bleed when I look at it. So anyway...I have a friend in the business of making things look good, so I'll share the wealth.

The current provider model in DotNetNuke is very flexible, but with that flexibility comes development overhead. Over the past few months I've started thinking about how much time I spend simply on [easy, repetitive] data access tasks, and its a little depressing.

1. Your latest DNN module utilizes in-line CSS like it was going out of style.
2. You frequently need to release new versions due to changes that consist solely of updates to hard coded strings in your code-behind.
3. 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
4. You FTP into the production DNN site to upgrade your module.
5. You spend more than 30 seconds packaging a new version of your module
6. 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.
7. 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.
8. The last time you upgraded your production environment you were up until 4AM trying to piece together outdated versions of your database.
9. 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.

I've installed a lot of DNN sites in the last couple of years, but this task just got even easier!

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.

With the new skinning changes in DotNetNuke, it may be helpful to give an overview of available approaches to skin developers.