Securing Edit and Admin

Table of Contents

Configurable HTTP Ports

Dynamic CSS Files

Follow the steps below to secure edit/admin and its ports on a default installation of EPiServer CMS:

       1.       Change the names of the edit and admin directories, e.g. c:\inetpub\episerver\admin to c:\inetpub\episerver\secretAdmin.

       2.       Change the EPsAdminDir, EPsEditDir, EPnEditHttpPort, and EPnAdminHttpPort using EPiServer CMS Manager. Ports can be omitted if you are only changing the directories.

       3.       Change the ports in the Internet Information Services (IIS) for the site where you wish to use custom ports. This step can be omitted if you are only changing the directories.

       4.       Change the <location path=”edit”> and <location path=”admin”> to correspond to the changed directories.

       5.       Edit the settings for the SysRoot and SysRecycleBin page types in Admin mode and change the path in the "File name" field so that it directs to the new edit directory.

       6.       Make sure that the ASP.NET account has read/execute permission for the new directories.

If a section begins with the text “No changes needed in existing applications", it means that the application does not need any modifications to work with relocated directories for that particular section in EPiServer CMS. The rest of the text in the section is merely for informational purposes.

The edit and admin directories are not hardcoded in EPiServer CMS 4.50 and later. Instead, there are two new keys in web.config that define the virtual directory locations:

Applications can access these values by reading the new EditDir and AdminDir properties in the ApplicationConfiguration object. If the keys are not defined in web.config, EditDir and AdminDir will return default values “edit/” and “admin/” respectively.

The values returned by the EditDir/AdminDir properties have the format “path/”. To simplify their usage they are guaranteed to always have a trailing “/” and never a leading “/”, even if defined otherwise in web.config.

Language Keys

No changes needed in existing applications.

All language keys work as previously - they are not affected by any directory relocations. This is also true for relative language keys, i.e. keys that are prefixed with “#”.

No changes needed in existing applications.

The plugin loader in EPiServer CMS 4.50 and later knows how to handle relocated directories. Any references to “~/edit/” and “~/admin/” in the Url property in the plugin attributes are automatically mapped to the real directory locations. This is an operation that is completely transparent to the plug-ins. Therefore, plug-ins that refer to files in edit/admin in their plugin attributes can continue to do so.

Example:

Hardcoded Paths to edit and admin

Hardcoded paths that refer to the edit and admin directories need to be changed. To help developers with this, the following is available:

Properties in the ApplicationConfiguration object

There are also properties for Http ports – see the Configurable Http Ports section for the details.

The UrlUtility class in the EPiServer.Util namespace contains the following methods:

The ControlLoader Web control:

References to User Controls in edit/admin

From a security point of view, it is best if you avoid references to user controls in the edit and admin directories altogether. But if your application requires this anyway, follow the guidelines below to ensure that your application will work even if the directories are relocated.

Replace any user control declarations using the <%@ Register syntax with the ControlLoader Web control. Do this when:

• You are using a user control located in the edit directory from a Web Form or user control outside edit.

or

• You are using a user control located in the admin directory from a Web Form or user control outside admin.

If you reference a user control from a file in the same directory, it is OK to use the ASPNET user control registration syntax, as long as you do not use “~/” or “../” in the URL. What happens when you use the “~/” or “../” syntax is that when the page is loaded runtime, ASPNET resolves the URL to an address that corresponds to the file’s location at design time. This is not necessarily the same as the runtime address, since the directory that the page resides in may have been relocated.

In the following example, a file in edit references the CommandActions.ascx user control, also a file in edit:

References to edit and admin Using “../”

In files both inside and outside the edit/admin directories, replace any URLs that begin with “../edit/” or “../admin/” with URLs that are based on the current site’s configuration. This applies to nested directories as well, for example “../../edit/”.

A good rule: files inside the edit and admin directories should always refer to other files using URLs that are built from EditUrl/AdminUrl in ApplicationConfiguration or the ResolveUrl method in the EPiServer.Util.UrlUtility class. As a rule, avoid references to files using the “../” syntax altogether.

For example, in files inside edit/admin:

For example, in files outside edit/admin:

References to files outside edit and admin Using “../”

When referencing files that are outside secured directories, the URLs can be relative to the site’s root (protocol and port information not necessary). Make sure that the URLs are relative to the site’s root and do not use expressions like “../dir1/dir2/file.css”.

For example, in aspx/ascx files inside edit and admin:

Configurable HTTP Ports

Overview

The HTTP ports used to access edit and admin directories are configurable in EPiServer 4.50 and later. Applications that rely on the default ports 80 (default HTTP port) and 443 (default HTTPS port) will probably need to be modified to handle unknown ports.

Configuration Properties in web.config

There are 2 values in web.config for HTTP ports configuration:

The port values can be accessed using properties in the ApplicationConfiguration called AdminHttpPort and EditHttpPort.

Requirements

To enable configurable HTTP ports, the spidersupport HTTP module must be defined in web.config. The module is defined by default in standard installations.