Starting with DotNetNuke v3.3/4.3, all dependencies on the Microsoft MemberRole assembly were removed. DotNetNuke includes a Role Provider, a Profile Provider and a Member Provider that works directly with ASP.Net membership. When the MemberRole dependency was introduced in DotNetNuke v3.x, many portal administrators who used the multi-portal Single Sign-On capability in DotNetNuke v2.x had to resort to third-party solutions to make SSO work across portals. With DNN v4.3 (possibly v3.3 also; I have not tested), it looks like SSO, or at least the potential for SSO is back.

If you add a row for a user in the UserPortals table, the user will effectively be able to authenticate seamlessly to every portal for which her/his user ID has a portal ID assigned. It’s that simple. Everything works as you would expect — roles are portal-specific; the user’s profile is portal-independent and authentication works regardless of which portal a user initially logs into.

Implementing a UI for administering SSO looks to be as simple as having a module where you can link/unlink users to/from portals. Nice.

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?