DotNetNuke Cross-Portal Symbolic Link Folder Provider

More details about this project may be found on my blog.

Description

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.

Goals

  • Seamless integration of the file system on a parent portal with its child portals
    • Parent portal files and folders should appear in the File Manager just like any other internal files,
    • Parent portal files and folders should appear in the core URL control, and
    • Parent portal files and folders should appear in the HTML editor and associated dialogs, and
    • Insofar as is feasible, files and folders should be indistinguishable from their parent-portal counterparts.
  • For the purposes of this integration, we link parent and child portals by their aliases as follows:
    • Child portals are evaluated using their first (e.g., primary) alias.
    • This portal alias is transformed by removing the rightmost path token (e.g. "/parent-portal/child-portal" is converted to "/parent-portal")
    • If a portal exists with this transformed alias, it is considered to be the parent of the child in question
  • Whenever possible, utilization of direct URIs to parent portal resources (and eschewing LinkClick.aspx where possible).
  • Require no core changes and utilize only existing DotNetNuke extension points

Background

The DotNetNuke content management system is a mature, robust, and widely-adopted web application framework. It offers multiple file persistence options out-of-the-box, including file-system storage (both unsecured and secured by ACL), along with ACL-secured database storage. When creating a link to a resource, the DotNetNuke UI provides a convenient list of these files, and also allows direct input of arbitrary URI. Recent versions have introduced an extension point by which developers may extend the file system to aggregate data stored in arbitrary locations. These providers have been used to add Amazon S3, Microsoft Azure, Sharepoint, and Dropbox support seamlessly within the application environment.

However, this folder provider extension point is not limited to merely linking to well-known cloud platforms. Indeed, at a very high level this extension point serves as an abstract directory and data streaming service that may be utilized in a variety of manners to achieve advanced requirements. As an illustration of this point, this project exists to demonstrate the power of this extension point to fulfill novel requirements.

After installing this concrete provider, administrators may create symbolic links from a child portal to the parent portal file system. In this way resources may be shared between portals in a natural, intuitive manner. Child portal administrators may select from and deploy these resources as if they existed directly on the child portal file system. Further, external resources (e.g. Amazon S3 data) are exposed in a manner identical to that presented on the parent portal, allowing deployment scenarios that were previously not possible.

The resulting symbolic link between parent and child portal is read-only (child portal administrators may not create or modify files on the parent file system) and only anonymously-accessible files are exposed.

Installation and Documentation

See the documentation page for details on installing the provider and configuring a symbolic link.

Note that in virtually all circumstances no more than one symbolic link need be created on a child portal.

Feedback, Reviews, and Ratings Appreciated!

Feedback about your experiences is needed, and greatly appreciated!

Last edited Dec 5, 2011 at 12:28 PM by BrandonHaynes, version 11