Sitecore SPEAK Gotcha #2 The StackOverflow exception when ID is part of your Entity

Using Sitecore Services Client is fun, but when the unexpected occurs it can be quite confusing to work out what is going on.

Last night was one of these cases; my code was constantly throwing a StackOverflow exception and I couldn’t understand why. There was no real indication and expected break points in code were not being hit.

After hours of scratching my head I decided to go back to basics with the Entities that I was using in part of my solution. It turns out that one of my Entities had an ID property which was causing the issue.

This is an example of the Entity I was using:

public class Template : Sitecore.Services.Core.Model.EntityIdentity
 public string itemId
 get { return base.Id; }
 set { base.Id = value; }

 public string TemplateName { get; set; }

 private ID _templateId = new ID();
 public ID TemplateID
 get { return _templateId; }
 _templateId = value;
 private List<string> _fields = new List<string>();
 public List<string> Fields
 get { return _fields; }
 set { _fields = value; }

The majority of the Entity above is simple enough, however having an ID property will cause a StackOverflow exception (so it seams). What was confusing though is that when invoking my service manually through a browser I did not experience any issues, only when invoking through a SPEAK application (through the fetchEntity function). Fiddler also confirmed that there was a difference between manual invocation and via the fetchEntity function.

What was going on? A SPEAK application (and related JavaScript) needs to be able to understand the information that is contained in your entities prior to using them (e.g. for client side validation). Currently, only the following simple types are supported:

  • string
  • bool
  • int
  • float
  • double
  • long
  • DateTime
  • Enum

(this is taken from the documentation at:

What I’m going to take a look at is to see if there is a way of extending this to include other types (such as ID). For now, I’m simply using strings for ID’s until I can find an alternative solution 🙂

Sitecore SPEAK Gotcha #1 Populating itemId from your Entity

Just a quick post regarding a small gotcha I experienced with Sitecore Services Client.

Recently whilst setting up some services with SPEAK and Sitecore Services Client I experienced the following error when calling the “fetchEntities” from my SPEAK app to return information from my Template Service (a service that I’m creating to teach myself Sitecore Services Client and SPEAK – full blog post to appear soon regarding its creation)

Below is the JavaScript I’m using to retrieve my information:

var result = templateService.fetchEntity(selectedItem).execute().then(function (template) {
var title = template.Fields;

When inspecting this in the console of Chrome I was noticing the following:

404 (Entity does not exist)

This seemed a little strange, as the entity was present and my code was certainly creating and returning the data (debugging verified this). So why was this appearing?

Well, it appears that in your Entity, you need to populate “itemId” field in the base class (Sitecore.Services.Core.Model.EntityIdentity), otherwise the 404 error will occur.

Huge thanks to Mike Robbins @Sobek1985 for this 🙂

Sitecore Services Client – Creating a Custom Authorisation Filter

Recently I’ve been looking into the Sitecore Services Client with interest. Sitecore Services Client was developed to provide a consistent way of integrating Client applications with Sitecore. There are many applications for this. You may have a client application (A SPEAK application, or a Single Page Application on a website) or even other systems acting as a “client” which requires to call Sitecore for information.

Sitecore Services Client is very extensible. The aspect I’m going to touch upon in this post in authorisation of requests.

The scenario I’m going to use for this is “Only authorise Sitecore Services Client if the IP address of the caller is the same as Sitecore itself”. This scenario could be useful if you had a bunch of services that are only designed to be available from applications that execute on the same box.

To do this, I’m going to create a LoopbackAuthorisationFilter which is designed to only authorise requests that origniate from the same IP address.

Firstly, create your class, inheriting from AuthorisationFilterAttribute (in the System.Web.Http.Filters namespace) and override the OnAuthorization function.

public class LoopbackAuthorisationFilter : System.Web.Http.Filters.AuthorizationFilterAttribute
        public override void OnAuthorization(HttpActionContext actionContext)
            // Play nicely with the base class

            // If the request does not originate from this machine
            if (!System.Web.HttpContext.Current.Request.IsLocal)
                // Create an Unauthorised Access response
                actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized, "Unauthorised Access");

What I’m doing here is ensuring that the original request originates from the local machine (with the same IP address). If the originating request is different, create a HTTP Unauthorized response back to the caller.

To wire this up in Sitecore Services Client, all you need to do is to add an entry into the section of the Sitecore.Services.Client.config file:

<filter>SSCActionFilter.LoopbackAuthorisationFilter, SSCActionFilter</filter>

It’s as simple as that 🙂

I have an example project on GitHub for you to try if you wish which will compile a DLL for you to use with your Sitecore Serice Client implementation:

Whilst this filter is simplistic, it is very easy to extend it to cater for any scenario you require, or even create your own Authorisation Filter.

Hope you have fun with this!

To find out more about the Sitecore Services Client, have a look at the Developers Guide to Sitecore.Services.Client here: