Skip to main content

Headless Sitecore Experience Editor Middleware series

This blogpost is part of a short series on Headless Sitecore Experience Editor Middleware


Over the course of the past 1.5 years, I have gained extensive experience working on multiple headless Sitecore projects where I’ve been able to construct decoupled, high-performance, and scalable front-end applications that seamlessly integrate with Sitecore’s powerful CMS capabilities. Most of these projects utilized the Sitecore JavaScript Rendering SDK (JSS) in combination with Next.js, but my current project is leveraging the Sitecore ASP.NET Core Rendering SDK. All of these projects have been using headless SXA as well for quickly scaffolding the Tenants and Site creation.

One important aspect of these frameworks is their ability to handle requests from the Sitecore Experience Editor, which allows content editors to modify and preview website content. In this series of blog post, I aim to explore the nuances of the endpoint configurations in the Sitecore ASP.NET Core Rendering SDK and the Sitecore JavaScript Rendering SDK (JSS), focusing specifically on the middleware responsible for managing requests from the Sitecore Experience Editor and deep-diving into that.

The previous blog-post was on the Next.js Sitecore JavaScript Rendering SDK (JSS), this one will focus on how the Experience Editor Middleware works in the Sitecore ASP.NET Core Rendering SDK.

Sitecore ASP.NET Core Rendering SDK Endpoint:

In the ASP.NET Core Rendering SDK, the Experience Editor Middleware handles requests from the Experience Editor. By default, Sitecore uses the following route for this purpose:

  • /jss-render

This endpoint is configured in the Experience Editor Options class:

In the Experience Editor Middleware class a check is made if the request is an Experience Editor request:

As you can see here this route differs compared to the Next.js API route where it is defined as:

  • /api/editing/render.

When the ‘/jss-render’ endpoint is posted/invoked, a series of operations take place to handle the request and generate the appropriate response.

  • Step 1: Middleware Execution: The HTTP request reaches the middleware pipeline in the ASP.NET Core application. The Experience Editor middleware is invoked and receives the HTTP context.
  • Step 2: Request Validation: The middleware checks if the request is an Experience Editor request based on the HTTP method and endpoint path. If it’s not an Experience Editor request, the middleware passes it to the next middleware and exits.
  • Step 3: Request Parsing and Verification: The middleware parses the request body, extracting relevant information. It verifies the JSS_EDITING_SECRET to ensure request authenticity.
  • Step 4: Sitecore Layout Content Extraction: The middleware deserializes the Sitecore layout content from the request body.
  • Step 5: Mapping Sitecore Item Path: The middleware determines the Sitecore item path based on the layout content and request information. It maps the item path if necessary using a SitecoreLayoutResponseMapper.
  • Step 6: Setting HttpContext Features for Next Handler: The middleware prepares the HttpContext for downstream middleware. It creates a SitecoreRenderingContext with the layout response content. The request method is changed to GET, and the path is updated accordingly.
  • Step 7: Execution of Next Middleware: The middleware calls the next middleware in the pipeline with the modified HttpContext. The HttpContext passes through the remaining middleware components.
  • Step 8: Response Modification and Finalization: The response from the downstream middleware is captured in a temporary buffer. The buffer is read, and the response body is extracted. The original response stream is restored. The response body is modified to match the Experience Editor’s expected format. The modified response is written to the original response stream and sent back to the client.

By following these steps, the EditingRenderMiddleware facilitates a seamless integration between the Sitecore Experience Editor and the headless Sitecore ASP.NET Core application, allowing for efficient editing and previewing of content within the Sitecore CMS environment.

In the next blog-post we’ll give a summary and how we can configure it with Sitecore Headless SXA. Stay tuned!

Happy Sitecore-ing!

–Robbert