Release: Cross-Portal Symbolic Link Folder Provider
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.
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.
Project 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.
- 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
Configuration and Usage
Installing the Extension
This provider is installed just as any other module or provider through the Host->Extensions menu option. Note that the provider requires DotNetNuke version 6.0.2 or greater; ensure that your installation meets this minimum requirement before proceeding. However, due to a (now corrected) issue with the DotNetNuke framework, an issue with some types of links exist on child portals that may cause problems when referencing external data. This issue has been corrected with the 6.1.2 release.
To Install:
- Log in as a host user
- Install the Cross-Portal Symbolic Link File Provider install package,
Configuration and Usage
Mapping the Symbolic Link Provider to a Child Portal
- Log on as an administrator of a child portal
- Visit the File Manager
- Hover over the Manage button and select “Manage Folder Types”
- Select “Add New Type”
- Create a name for the provider mapping (e.g. “Symbolic Link”) and select the provider type (“BrandonHaynes.Providers.SymbolicLinkFolderProvider”)
- Save the mapping
Adding a Symbolic Link
- Log on as an administrator of a child portal
- Visit the File Manager
- Select “Symbolic Link” from the folder-type drop-down
- Enter a name for the symbolic link, and select add
(Note that in virtually all circumstances no more than one symbolic link need be created.)
Your Feedback is Needed!
As this project moves toward an initial production release, it will rely heavily on the feedback provided by the community. Any such feedback — including comments, ratings, and constructive criticism — is greatly appreciated.
