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.

 

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.

  

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.

Airport monitor

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?

 

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.

Melbourne tram schedule display

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 Posted by nik at 8:00 am

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.