.NET Core Renderer as a proxy
To have seamless experience when using the standalone Renderer application together with Sitefinity CMS, the Renderer is also working as a proxy and forwards every request it cannot handle to Sitefinity CMS. This way, the user does not have to switch between the two applications.
You host the Renderer at your public domain and your users use only this domain, without considering whether the Renderer or Sitefinity CMS will handle their request.
NOTE: The proxy logic facilitates the migration of Sitefinity CMS pages that are created with ASP.NET MVC to the new ASP.NET Core pages, created with the Renderer application.
All Renderer related styles, scripts, and other resources that are for system use are located under the
If another resource coincides with a resource under ~
/sfrenderer, the renderer resource is handled with higher priority and is not forwarded to Sitefinity CMS.
Every other request is forwarded to Sitefinity CMS. Then, Sitefinity CMS decides whether to handle the request or to delegate it to the Renderer. This means that every backend request for the Admin App interface, for Web APIs for pages, images, and so on, is proxied to Sitefinity CMS.
NOTE: You can host all client related resources and services under any route. However, you must choose the route in a way that Sitefinity CMS resources do not conflict with Renderer resources – for example, Images. In case of conflict, resources from the Renderer are handled with higher priority.
RECOMMENDATION: We recommend placing every custom resource either under
/sfrenderer, or choosing a unique custom route – for example,
Each forwarded request has a custom header attached -
SF-RENDERER-PROXY=true. This way, Sitefinity CMS knows whether to delegate the page rendering to the Renderer or to handle it.
By leveraging this approach, the user can simultaneously work with Sitefinity CMS pages created with ASP.NET MVC, as well as with pages created with the new ASP.NET Core Renderer application.