Class Projections and Projection Classes

The purpose of this post is to raise the profile of a powerful mechanism that has long been available to us, and to open a discussion about ways in which it can be used or abused.

You can read more detail about the mechanism in the InterSystems documentation. To summarize, your class definition can use the Projection keyword to reference one or more projection classes. A projection class can implement methods that get invoked at key points in the lifecycle of your class.

A projection class must extend %Projection.AbstractProjection and will typically implement at least one or the following methods:

• CreateProjection
• RemoveProjection

CreateProjection will be called after your class has been compiled. RemoveProjection will be called just before your class is recompiled, or just before it is deleted.

I think one of the original uses of this mechanism was to generate Java files that implemented a Java projection of an InterSystems class. Since then, it has been used more extensively and become more sophisticated. In InterSystems IRIS 2021.1 I found twenty-six %-classes that derive from %Projection.AbstractProjection.

Apart from how InterSystems uses the mechanism I have also seen it exploited in other ways. Here are a couple of examples:

• UMLExplorer ships as an XML file containing four classes. One of these is a projection class called ClassExplorer.WebAppInstaller, which ingeniously projects itself:

Class ClassExplorer.WebAppInstaller Extends %Projection.AbstractProjection
{

Projection Reference As WebAppInstaller;
...

So when this class is compiled its CreateProjection method executes, performing whatever steps the developer coded there. In this case it adds a web application called /CacheExplorer, but it could do anything that the permissions of person compiling the class allow.

• A site using our Deltanji source code management tool created a utility projection class. Whenever they are deploying a piece of work that requires some installation steps to run in a target namespace, they implement those steps in a deployment class (D) that has a projection referencing their utility projection class (P). Then they bundle (D) with the piece of work. When (D) gets loaded and compiled in a target namespace the CreateProjection method of (P) is automatically invoked, and is passed the classname (D), allowing it to invoke methods of (D).

If you've seen projection used in other ways, or if you've devised a novel use yourself, please share it as a comment on this post.

One more thought from me at this point. The mechanism means we should probably think twice before compiling during import an XML file whose contents we aren't sure we can trust. The scope for a malicious projection class is great.