From the Desk of Brandon Haynes

I am pleased to announce a beta release of my role-based control panel extension.  It may be downloaded via CodePlex on its project homepage.  As is all of my DotNetNuke work, this project is fully open-source and available under a liberal BSD license.

The DotNetNuke content management system exposes a control panel to administrators, allowing for site and (in the case of host users) installation administration. Historically some components of these administrative tasks (the “Admin” menu) were displayed alongside the main site navigation, however, after version 6.0 this component was moved out of this navigation area and consolidated into a single interface. This served to reduce the layout differences between ordinary and administrative user, and greatly enhances the user experience.

However, while in previous versions it was possible to assign access permissions to some administrative components (e.g. access on the “Admin” menu or page-editing permissions) to users who were not members of the Administrators group, some delegation-related use-cases were deprecated in version 6.0. While users who have specific permissions (e.g. the ability to edit a specific page or module) may be granted access to some subcomponents of this enhanced control panel, some functionality is restricted only to those in the “Administrators” role. Stated another way, in order to view the control panel an individual must be (i) in the Administrators role, (ii) visiting a page that is editable by that user, or (iii) visiting a page with a module that is editable by that user.  It is not possible to display the “Admin” control panel option to users who have permission but do not meet the criteria above.

Additionally, the ability to present a “control panel-like” interface on a site-wide basis is an interesting use-case. For example, Facebook presents a toolbar to authenticated users that is visually similar to the DotNetNuke control panel. The ability to display a control of this type to authorized users would enable this sort of functionality not presently possibly without tedious workarounds (e.g. including an additional module on each page).

Accordingly, this project is designed to expose the ability to instantiate a control panel on a per-role basis, with the intention that functionality delegated to non-administrators may be exposed via an alternate control panel that contains only that functionality relevant to those users.

I am pleased to announce a beta release of my cross-portal symbolic link folder provider.  It may be downloaded via CodePlex on its project homepage.  As is all of my DotNetNuke work, this project is fully open-source and available under a liberal BSD license.

The DotNetNuke content management system is designed with multi-tenancy in mind, and allows an arbitrary number of websites (“portals”) to be created therein. These portals may be configured at the root of a given domain (e.g., “http://dotnetnuke.com”) or as a child portal below the root of a portal hierarchy (e.g., “http://dotnetnuke.com/mychildportal”). Historically these child portals have had no structural link to their parent counterpart, other than sharing a similar base URI.

This provider is designed to expose the file system in a parent portal to all child portals via specially-formed symbolic links. This allows administrators of child portals to access and utilize these files in a natural manner via existing dialogs and other DotNetNuke services. It creates an implicit linking between these two portal entities, and in configurations where there is significant overlap in data usage between parent in child portal (for example, when a child portal represents a single department within a larger corporate environment) allows for greatly simplified administration.

The slides for my recent presentation (on file system abstraction) at DotNetNuke World 2011 are located here.  Note that there are several changes here that are not realized in the slides available through the conference site, though these are primarily pedagogical in nature.

I will be releasing the source for the cross-portal symbolic link folder provider later this week.  Note that, for URIs that are processed via the link-click handler, this provider relies upon a yet-unreleased fix in 6.1.2.  For ordinary direct-access URIs the provider functions as expected.

The W3C Indexed Database API working draft defines an method by which a developer may operate on a set of indexable object stores persisted in a client’s web browser environment. Values in an object store or index may be associated with a developer-specified primary/secondary key, or alternatively keys may be automatically generated based upon the value inserted. Left-, right-, full-, and un-bounded cursors are supported in both the forward and reverse direction. Each connection supports up to one active transaction across any set of open object stores (as is elucidated by the working draft).

The working draft exists as a incremental improvement over previous specifications (e.g. web storage) in that robust indexes and duplicate keys are supported. Indeed, an object store may have an arbitrary number of such indexes, each manually or automatically populated according to a developer’s needs. This API allows for advanced data scenarios on the client that were until now quite difficult (or not possible).

Unfortunately, there currently exists no reference implementation for this working draft. This project serves to fill this need, and exists as a browser plug-in that implements the API defined by the working draft.

Introducing Our Second Harvest Virtual Food Drive

I recently had the privilege of teaming up with some fellow Harvard University graduate students to support a national food-and-fund drive to benefit the Second Harvest Food Bank of Santa Clara and San Mateo Counties.

This Second Harvest organization was a perfect choice as it is highly efficient, reputable, and provides critical food support year-round for those in need. Moreover, Second Harvest has an unsurpassed dollar-for-deed ratio: 95% of every tax-deductible dollar donated will directly feed families and individuals in dire need of assistance. In this way, contributions will make a powerful difference!

Second Harvest: Built on DotNetNuke

Equally important for many readers of this blog, this Second Harvest organization utilizes DotNetNuke as a platform for donations, food drives, and in communicating its important mission. It is especially fulfilling for me personally to be a part of an open-source platform that is utilized to help those in need, and I am confident that anyone who has ever contributed to or supported the DotNetNuke ecosystem in any way feels the same.

Second Harvest of Santa Clara and San Mateo Counties is a fantastic example of a great charitable model combined with some excellent technology choices. Any charity that is able to return 95% of its contributions to those it is trying to help easily meets this bar, and Second Harvest leverages DotNetNuke to accept donations in a meaningful way from contributors around the country.

Please Consider Supporting Second Harvest

Throughout 2009, I have contributed a number of software projects to the public domain (including Amazon S3 integration, Entity Framework and LINQ to SQL model adapters, multi-factor authentication, a mega-menu provider, et cetera). If you have found any of those projects beneficial, or otherwise feel a need to help those in need, please consider making a contribution.

Nothing else matters when you’re hungry. Give a gift that matters at this critical time. If your cupboards are full, please help others who don’t know where their next meal will come from. No donation is too small; giving as little as $10 is enough to provide 20 people with the most basic human need: food.

This is a great opportunity to ensure that children, families, and seniors don’t go hungry.

Please join us in this effort to assist the less fortunate who have to decide between paying for rent, utilities, or medicine and providing food for their loved ones.

Donations may be made via the Second Harvest website.

After lingering in limbo for some time, I am pleased to be able to provide some screenshots of my upcoming DotNetNuke Module Container project.  This project is expected to be released into beta sometime in mid-November, though I may circulate to a few interested parties before any public release.

The project is designed to address a common usability concern with the default DotNetNuke control panel, which is perhaps best illustrated pictorially:

A Scary DotNetNuke Menu with Many, Many Options

As users of the framework have surely noted, the list of modules available to an administrator is lengthy and highly-confounding.  While experience mitigates this difficulty, it remains a significant challenge for new administrators to understand which module to select from this imposing list.

This project attempts to group this set of modules into manageable containers where each module is grouped by function (e.g. administrative modules, e-commerce modules).  By way of example, a clean DotNetNuke 5.1.4 install with ALL core modules installed (and grouped into logical containers) would be reduced to a very understandable list:

A compact, minimized DotNetNuke control panel module list with groups by function. Note that the image above continues to utilize the default DotNetNuke control panel; the containers do not require any adjustment to that component.

After a container is selected and instantiated, a user is prompted to select from one of the modules contained therein:

Interactive selection of a module within a grouping after selecting the group from the control panel.

The selection process utilizes jQuery, minimizes the number of post-backs, and (in my opinion) greatly increases overall usability.

This module is expected to be released sometime in mid-to-late November for public consumption.  A limited beta may be made available prior to this date, subject to interest.

Your feedback is appreciated.  Does the lengthy DotNetNuke module list bother you?  Would you (or your administrators) find a solution of the type outlined above useful?  Please leave a comment and share your thoughts.

B

The Entity Framework ObjectContext allows for development using a model automatically generated by a Visual Studio designer. However, when deployed within DotNetNuke, these attributes do not pick up the database owner and object qualifier required for correct inter-operation.  Because of this, large-scale deployment of modules using the Entity Framework is infeasible, and modules using the technology are unfortunately limited to internal applications.

To remedy this issue, I have developed an adapter that converts the Entity Framework model generated by the designer into a DotNetNuke-compatible model that uses both the object qualifier and database owner specified by an end-installation.  This adapter is based off of the more generalized model adaptation framework that I recently released.

My goals for any satisfactory solution were as follows:

This solution extends the Entity Framework runtime model adapter to operate within a DotNetNuke extension, allowing a developer to design against an unqualified, dbo-owned DotNetNuke instance and be assured that it will deploy (and operate) correctly on any configuration that an end user might have deployed. Adaptation is largely inexpensive, and since the models are cached by type, performance is not significantly affected.

Click here to access the project site for additional details and downloads.  Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

As always, feedback is greatly appreciated.

B

Over the last few months, I have been doing some initial architectural research regarding the integration of DotNetNuke with arbitrary external e-commerce systems.  Note that this research is highly embryonic, largely experimental, and highly likely to not reach any sort of production-ready fruition.  Its purpose is to inspire discussion, not demonstrate code.  Caveat lector!

As one of my goals is reasonable provider-independence (via adaptation), this is not about realizing any particular vendor (despite the fact that I address one specific such vendor herein).  That said, I have been asked by several parties to share a bit more about where this stands; it is with this in mind that I present an initial update.

I am pleased to make available a whitepaper detailing the high-level motivation and approach involved in the creation of the recently-released DotNetNuke Multi-Factor Authentication Provider, along with a discussion of the unique characteristics of a DotNetNuke installation that render the approaches of other vendors (e.g. RSA SecurID) incomplete or unsatisfactory. Additionally, each out-of-the-box factor is described in general detail in a format that is digestible by an audience of varying technical sophistication.

This paper is intended for all audiences who might have an interest in overall DotNetNuke installation security, and is designed to assist management in identifying an appropriate level of authentication-related risk.

• Download the Multi-Factor Authentication in DotNetNuke Whitepaper
• Learn more about the Multi-Factor Authentication Provider
• Learn more about the DotNetNuke Web Application Framework