In V5.3 it is possible to completely disable security for all descendants of WebControl (including XslFile). Simply set the property 'DisableSecurity' to 'true' on the control.

For XSLT files, we have created two new XSL controls that can be used to enable and disable security for specific sections in an XSLT file.

An example is provided below:

<xsl:template match="*" mode="main">
  <h2>Security enabled</h2>
  <sc:enableSecurity>
    <xsl:for-each select="item">
      Child <xsl:value-of select="position()"/><br/>
      <sc:text field="@name"/><br/>
      <br/>
    </xsl:for-each>
  </sc:enableSecurity>

  <h2>Security disabled</h2>
  <sc:disableSecurity>
    <xsl:for-each select="item">
      Child <xsl:value-of select="position()"/><br/>
      <sc:text field="@name"/><br/>
      <br/>
    </xsl:for-each>
  </sc:disableSecurity>
</xsl:template>

The <sc:enableSecurity> surrounds its containing statements with a
Context.Security.EnterState(SecurityState.Enabled) and a Context.Security.ExitState().

The <sc:disableSecurity> surrounds its containing statements with a
Context.Security.EnterState(SecurityState.Disabled) and a Context.Security.ExitState().

After preprocessing, the code will look like this:

  <xsl:template match="*" mode="main">
    <h2>Security enabled</h2>
    <xsl:if test="true()">
      <xsl:value-of select="sc:EnterSecurityState(true())" />
      <xsl:for-each select="item">
      Child <xsl:value-of select="position()" /><br />
      <xsl:value-of select="sc:fld('@name', .)" disable-output-escaping="yes" />=
      <xsl:value-of select="sc:fld('title', .)" disable-output-escaping="yes" /><br /><br /></xsl:for-each>
      <xsl:value-of select="sc:ExitSecurityState()" />
    </xsl:if>
    <h2>Security disabled</h2>
    <xsl:if test="true()">
      <xsl:value-of select="sc:EnterSecurityState(false())" />
      <xsl:for-each select="item">
      Child <xsl:value-of select="position()" /><br />
      <xsl:value-of select="sc:fld('@name', .)" disable-output-escaping="yes" />=
      <xsl:value-of select="sc:fld('title', .)" disable-output-escaping="yes" /><br /><br /></xsl:for-each>
      <xsl:value-of select="sc:ExitSecurityState()" />
    </xsl:if>
  </xsl:template>

1. Start the Sitecore Shell
2. Select 'Deactivate proxies' from the database menu (in the lower right corner next to the clock)
3. Open the Content Editor
4. Navigate to B
5. Create a new item below B from the template 'Proxy'
6. Fill in the field 'Target item' with the ID of E
7. Save
8. Select 'Activate proxies' from the database menu

1. If you copy the root of a shadow tree to another location, it is the underlying proxy item that is copied
2. If you move the root of a shadow tree to another location, it is the underlying proxy item that is moved
3. If you delete the root of a shadow tree, only the proxy item will be deleted.

Linking across databases

Children

API support for linked items

• Item.Runtimesettings.IsShadow: Specifies if an item is a shadow item.
• Item.Runtimesettings.IsProxy: Specifies if an item is a proxy (ie. it is the root of a shadow tree).
• Item.Runtimesettings.IsVirtual: Specifies if an item is either a shadow or a proxy
• Item.Runtimesettings.IsExternal: Specifies if an item is from another database than the host database
• Item.Runtimesettings.OwnerDatabase: The database that owns the item. The Item.Database property will always return the host database. To get the 'real' database owning an item use this property instead.

Data providers

Archives

Indexes

Linked items

Security

Workflows

1) Set up connection strings

Replace SqlServer reference with Firebird in web.config

Note: The following applies to Sitecore 5.1.0.7 and later.

To provide login functionality on a web site, you can use the loginPage attribute on the site definition. For instance,

      <site
        name="website"
        virtualFolder="/"
        physicalFolder="/"
        rootPath="/sitecore/content"
        startItem="/home"
        language="en"
        database="web"
        domain="extranet"
        loginPage="/layouts/login.aspx"
        allowDebug="true"
        cacheHtml="true"
        htmlCacheSize="10MB" />

In this case the loginPage points directly to a physical ASPX file. In case you want to point to an item instead, please remember to grant read access to Everyone on that item.

Now, whenever an anonymous user requests a protected page, he is redirected to the login page.

By contrast, if a logged-in user requests a page that he does not have access to, he is redirected to the 'no access' page and given the option to log in as another user (via a link at the bottom of the page).

Require login for all

If you require that all visitors to the site must log in, you can use the requireLogin attribute like this:

      <site
        name="website"
        virtualFolder="/"
        physicalFolder="/"
        rootPath="/sitecore/content"
        startItem="/home"
        language="en"
        database="web"
        domain="extranet"
        requireLogin="true"
        loginPage="/layouts/login.aspx"
        allowDebug="true"
        cacheHtml="true"
        htmlCacheSize="10MB" />

The configuration above will cause all requests by anonymous users to be redirected to the login page.

Misc. considerations

If you specify a domain without supplying a login page, unauthorised requests will be redirected to the value of Settings.NoAccessUrl (default: /sitecore/noaccess.aspx).

This page will simply inform the user that the request failed due to missing access rights.

If you set requireLogin="true" without specifying a login page, an error message will be shown telling that no login page has been specified in the configuration.

An often overlooked fact is that accessing the property Children of Sitecore.Data.Items.Item is a very expensive operation.

The reason is that the list of children is retreived from the data layer every time the property is accessed.

Basically the implementation goes like this:

    public ChildList Children {
      get {
        return new ChildList(this);
      }
    }

This is done to ensure that the list of children is always up to date.

Therefore, to improve performance of your code, you should access Children as few times as possible. For instance, the following code is not very effective:

  Item item = GetSomeItem();

  for(int n=0; n < item.Children.Count; n++) {
    MainUtil.Out("Child name: " + item.Children[n].Name);
  }

If the child count is 10, then the list of children will be reloaded at 20 times!

The code should instead be written:

  ChildList children = item.Children;

  for(int n=0; n < children.Count; n++) {
    MainUtil.Out("Child name: " + children[n].Name);
  }
 
That way the list is loaded only once. If, at a later point, you need the latest list of children, you can simply call item.Children again.

In retrospect, the Children property should not have been a property at all. It should have been a method with the name GetChildren(). That would have indicated the performance overhead. But alas, that's way too late now...

In Sitecore 5.1 we go from having one large cache (mapping to the ASP.NET cache) to using multiple custom caches.

The caches are all accessed through a common class, the CacheManager. This class has a lot of methods used for adding/removing data and performing other cache related functions.

Database caches

The credential cache stores information about user rights. For instance, when it has been determined that a specific user can or can not read a given item, this information is stored in the credential cache. Subsequent read requests can then be granted without requiring a full security scan for the user again.

The data cache stores data read from the data provider(s). The data is stored in a format that makes it very fast to access. Specifically, the cache contains objects of the type DataManager.DataContainer.

The path mapping cache stores information about previously resolved paths. For instance, if the system has already determined that the path "/sitecore/content/home" maps to the ID {110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9} it stores this information. The next time someone requests an item using the same path, the item can be retrieved very fast using the cached ID.

Site caches

The html cache stores the html output of renderings that have been set to Cacheable.

The xsl cache is used for storing compiled XSLT files in memory. This relieves the system from the need to recompile the XSLT's every time they are needed. Also, it helps keep memory consumption down when using inline code in XSLT's (as these can not be unloaded due to a limitation in .Net).

The registry cache is used by the Sitecore Client to store various user settings and would not normally be used by other applications.

The viewState cache is also an interal cache used by the Sitecore Client.

Cache sizes

Cache sizes can be set up either on a specific site or database definition or it can be specified in the <cacheSizes> section. The values set directly on a site or a database will always take precedence over the values set in <cacheSizes>.

The <cacheSizes> section should pretty much be self-explanatory. An example is shown below.

    <cacheSizes>
      <databases>
        <core>
          <data>10MB</data>
          <credential>1MB</credential>
          <pathMapping>1MB</pathMapping>
        </core>
      </databases>
      <sites>
        <core>
          <html>0</html>
          <registry>10MB</registry>
          <viewState>0</viewState>
          <xsl>0</xsl>
        </core>
        <website>
          <html>10MB</html>
          <registry>0</registry>
          <viewState>0</viewState>
          <xsl>5MB</xsl>
        </website>
      </sites>
    </cacheSizes>

The valid cache names for the <databases> element are:

  data
  credential
  pathMapping

The valid cache names for the <sites> element are:

  html
  registry
  viewstate
  xsl

To set a cache size directly on a site, use an attribute named xxxCacheSize where xxx is the name of the cache. For instance, to set the size of the html cache on the web site use:

  <site name="website"
    ...
    htmlCache="10MB" />

The size can be specified in bytes (no postfix), kilobytes (KB) or megabytes (MB). Spaces and dots are allowed in the value string, so the following is also valid:

  <site name="website"
    ...
    htmlCache="1.024 KB" />

To set a cache size directly on a database, you must use the properties on the database object (as the database object is constructed by Sitecore.Factory using only reflection).

To set the size of the data cache on the "master" database you can use:

  <database id="master" ...>
    ...
    <caches.DataCache.MaxSize>1000000</caches.DataCache.MaxSize>
  </database>

Note that the size must be specified in bytes (as the type of the MaxSize property is long).

Disable caching

By settting a size of 0 (zero) on a cache, the cache in question will be disabled. For instance, to disable html caching on the web site:

  <site name="website"
    ...
    htmlCache="0" />

To disable all caching whatsoever in the system, the global setting "Caching.Enabled" can be used like this:

  <setting name="Caching.Enabled" value="false" />

This setting is mostly for diagnostic purposes.

As a side note, individual data providers may also prevent their data from being cached by using the CacheOptions property on the DataProvider base class. For an example of this, see the file system data provider, which is defined like this in web.config:

      <filesystem
            type="Sitecore.Data.DataProviders.FileSystemDataProvider,
            Sitecore.Kernel">
        <CacheOptions.DisableAll>true</CacheOptions.DisableAll>
      </filesystem>

Welcome to the Sitecore API.