Bugle is a project that consists of Google queries that help identify security bugs in open source software. This is a very interesting concept and while it may help hackers find vulnerabilities in software easier than scouring the code, I think it is more useful for open source project teams.

By their very nature, open source projects are generally collaborative and therefore it is easy for unsecure code to creep in. The Bugle technique effectively helps detect high-level vulnerabilities in contributed code that has not been carefully scrutinized by the project security administrator.

This brings up another topic, which is better suited for its own post, but I will briefly mention here. While open source is supposed to result in more secure code because many more eyeballs are reviewing the code, the reality is that few people that use open source software actually look at the code. Most people are in it for the “free” aspect, not necessarily for the code. If the project developers miss a vulnerability in the code, it may not be detected for a long time. How is this any different from commercial, closed source projects? 

It’s easy to persist settings for an instance of DotNetNuke modules using ModuleController.GetModuleSettings(moduleId). But sometimes you want module settings to apply to all instances of a module within a given portal. I needed to do this for a module and used the following code:

PortalSettings portalSettings = (PortalSettings) HttpContext.Current.Items["PortalSettings"];
ModuleController moduleController = new ModuleController();
ModuleInfo moduleInfo = moduleController.GetModuleByDefinition(portalSettings.PortalId,"Site Settings");
int globalModuleId = moduleInfo.ModuleID;
Hashtable globalSettings = moduleController.GetModuleSettings(globalModuleId);

I suspect there may be better ways to achieve this objective, but this seems to get the job done. If anyone knows a better way please post in comments.

The schedule information displays for public transportation in the U.S. tend to range somewhere between ho-hum to crappy. Either you have the paper schedule posted under plexi-glass or you have giant, ugly LED or OLED displays. On my recent trip to Melbourne I was totally impressed with the displays at the tram stops.

This display rocks! It is clear, concise and most importantly, real-time (note wireless antenna at top). And the unit itself is compact and not an eye-sore.

There was one important UX choice that puzzled me at first. The display is sorted by Route # versus arrival time or destination. I pondered this for a bit and the decision does make sense. If the display were sorted in descending order by arrival time, you would have scan down the list to find when your tram or bus would be arriving. This way, you can quickly skip the Route #’s you are not interested in and quickly find the time your tram will arrive.

This made me think about the sorting choices in Windows Explorer. When you are in Details view and sort columns, no matter which column you choose, there is an implicit primary sort by type (i.e. folder or file) before the selected sort is performed. I faithfully reproduced this functionality in my File Manager Pro product, but have always questioned its usability. The way it’s implemented, when you are scanning the list, you have to look twice — once to find the type of item (folder or file) you are interested in, and then to find the item you are looking for.

Would the Windows Explorer Details view be more or less efficient and usable if the implicit sort by folder or file were removed?

I flew out of Dulles Airport a couple of days ago and found the Flight Departures monitor displaying some interesting information. Although you can't tell from the picture, the dialog showing is the "System is running low on virtual memory" that we have all seen at some point or the other.

The dialog stayed on the screen for the entire 45 mins. I was waiting for my flight to board. Although this is only an information screen, it still makes you wonder how much thought goes into fault tolerance and recovery on the systems that power such displays?

I have had several emails from people inquiring whether I would be releasing a My Modules version for DNN4. The answer is "Yes." I'm trying to decide if I should base it on VS.Net WAP or WSP models. If you are not familiar with these models you can learn more about them on Scott Guthrie's blog. 

I am trying hard to be objective, but I have a strong bias for the WAP model. Granted, it makes total sense for the DNN project to follow WSP since it allows DNN to be usable with the Express series of Microsoft developer products. However this is not an important consideration for most professional developers. Also, there is a significant cost to change all my existing projects to support the WSP model and it will take quite a bit of time to migrate and test hundreds of VS.Net 2003 projects and migrate them to the WSP model. I am sure there is some ROI there, but it's just not something that makes you sit up and take notice.

I have allocated some time this weekend to study the DNN Starter Kit in greater detail and make a decision on which model to follow for "My Modules." If you have any preference on the matter, please leave a comment or contact me using the link at right.

If you have a web application from which you want a user to be transparently authenticated to a DNN 4.x portal, you can do it quite easily using a URL. Assuming a scenario where the usernames/passwords are synchronized, an easy way to accomplish this is as follows:

1) Have a link or button on the web application which contains the username and password. Now, it goes without saying that you do not want this in plain-text and should encrypt both and share the key between the web app and the DotNetNuke portal. A good solution for this is Secure Query Strings. Since the referenced article does a great job of explaining how these work, I will not dwell on the topic.

2) At the receiving end (i.e. the DotNetNuke portal), you need an entry-point. A dedicated ASPX page is a logical choice. The code for the page needs to grab the querystring parameters and decrypt them. Once this is done, you have the credentials necessary to authenticate the user. The below code should do the trick:

using System;
using System.Web;
using DotNetNuke;
using DotNetNuke.Entities.Portals;
using DotNetNuke.Security;
using DotNetNuke.Common;

namespace DotNetNuke.RemoteAuthentication
{

         public class DnnAuthentication
         {

               public static bool Authenticate(
                                       string username, string password)
               {
                     PortalSettings portalSettings =  (PortalSettings)
                                 HttpContext.Current.Items["PortalSettings"];
                     PortalSecurity portalSecurity = new PortalSecurity();
                     string ipAddress =
                                 HttpContext.Current.Request.UserHostAddress;

                     if (portalSecurity.UserLogin(
                                                                username, 
                                                                password,
                                                                portalSettings.PortalId,
                                                                portalSettings.PortalName,
                                                                ipAddress,
                                                                false
                                                            ) == -1
                        )

                              return (false);

                     else

                              return (true);

               }

         }

}

The above solution is trivial and is going to be practical in a limited number of situations. However, it can be a good starting point for a more robust solution which may also include creating the user account automatically on the DotNetNuke portal.

A robust file synchronization utility is a must-have for anybody with multiple machines. I have tried many solutions and always found something to be lacking. And then I discovered MirrorFolder.

This product is simple, yet incredibly powerful. I have used it for six months now and couldn't ask for anything more. The thing I like most about this program is that after telling it what files/folders you want synchronized, you just forget about it. MirrorFolder does its thing in the background and without bothering you. No annoying system tray notifications, no emails, no popup windows...just sync'd files.

Using MirrorFolder, I now have my notebook (my primary development machine) happily sync'd hourly with my home server (which backups to iBackup.com nightly). I have yet to notice when the sync happens since it does not seem to impact resources in any meaningful way. While this setup works great when I am working in my home office, it didn't provide a good way to backup when I am mobile.

After researching my options, I decided that an ultra-compact USB drive is the way to go. The Seagate ST90000U2 fits the bill. This little drive is compact (5" x 3.75" x 1"), light-weight, totally silent and gives me 120Gb of portable storage using only USB power (no bulky adapter to lug around). I set MirrorFolder to sync with it when available so when I am travelling, all I have to do is plug in the USB connector at some point and I have a backup of all changes. (If I know I haven't made too many changes, and if I am in a hurry, I just use my Cruzer Mini 4Gb USB stick.)

On my recent trip to San Francisco and Australia, I used MirrorFolder and the Seagate drive. Both performed flawlessly and allayed my fear (paranoia?) about data loss.