DotNetNuke Cross-Portal Symbolic Link Folder Provider

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

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.