Server Side Page

The Server Side page allows you to run legacy software and 3rd party applications transparently within the CMS environment.


This allows you to take advantage of several features built into the CMS:

  • Editing code files using drafts
  • Approval Process
  • Publish history for code versioning, notes, and audit trail
  • Controlling Public, Non-Member, and Member access rights within the CMS
  • Automatically embedding existing server side files within CMS layouts for look/feel
  • Integration into website navigation (Global, Secondary, Site Map)
  • Transparent universal login for session impersonation


Server Side pages can be integrated with any web server language.  Some examples of languages that can be integrated are:

  • PHP
  • Perl
  • Cold Fusion
  • Python
  • ASP
  • Java

Behind the Scenes

Server Side pages act as an HTTP proxy, making requests on the user's behalf, then returning the results to the CMS engine, where it is then modified for HTTP path corrections with other Server Side pages.  This allows the user to navigate through what appears to be a standard ASP.NET page, which is actually running any server side language.  Behind the scenes authentication, which is customizable, enables the external request to impersonate the current CMS user's session, within the HTTP proxy request.

Special comment tags are used to identify which areas of the request should be dropped, to properly frame the HTTP output within the CMS layout.  A special comment tag is also added to the server side login redirect, to identify it as a login request, which can then be authenticated before continuing to serve up the original HTTP proxy request.


The Server Side page does not enhance the security of the existing page it is acting as a proxy for.  If an exploit exists in the legacy code, it will still be accessible to a malicious user.  What might increase security due to oversight is that the legacy code will appear to be running within ASP.NET, so exploits specific to another server side language will not be easily identifiable.  Additionally you can lock down access to the page using the built in CMS access restriction mechanisms.


The Server Side page should appear in the Page Types key in the CMS Website Tree.  If it does not and you are interested in using the Server Side page, please contact support.


A typical scenario where you'd use the Server Side page might be as follows:  To integrate with some Cold Fusion files, you would create a Server Side page to represent each file.

Editing Server Side Pages

Editing the Server Side page is very similar to editing a text file using the Text File Page type.  Upon Save & Publish the file is physically written to disk.  The physical file path should match the physical path relative to the website root, to access the Cold Fusion file.  The Friendly Url can be any value, and will be accessed from the /Content folder.

Server Side Page Properties

The following properties exist and can be modified depending on desired behavior:

  • Signature Start / End: The tag values to identify the beginning and ending of the usable content area that should be embedded inside a CMS layout for look/feel integration
  • Username / Password: The username/password values that should be passed to the Server Side file via HTTP proxy request for session impersonation; these values are typically going to be CMS session variables
  • Application Name: The Server Side page can be used for multiple 3rd party or legacy applications, so an Application Name can be used to identify each HTTP proxy session pool separately
  • File Types: File extensions used to identify potential URLs that should have path correction applied
  • Session Vars: Session variables that should be passed as Request parameters through the HTTP proxy request to the server side file
  • Login Url: The URL used for session impersonation to authenticate the current CMS user with the current server side file request



Server Side pages are intended to reduce time and cost of integration by extending the lifetime of existing software applications while integrating with the latest web technologies.  This does not necessarily mean a web application written long ago with potential exploits should continue to be used in production when it is possible to write a secure, updated version with the latest technological enhancements.

Contact this Author: < Nicholas Bott >