A Little Change In Sitecore 9 That Could Have A Big Impact
There has been a lot to talk about in the Sitecore Community since the release of Sitecore 9.0. Some of big and interesting changes have been around the following:- SIF: The Sitecore Install Framework
- xConnect: The new interface into the xDB
- xDB on SQL Server
- The new Layout Service & JSS: JavaScript Services for Sitecore
- Secure By Default
- Out-Of-The Box Dynamic Placeholders
- Support for Federated Authentication (such as ADFS)
- etc.
With all this to write about, I feel like a major change to the way Sitecore has worked for as long as I remember is not getting the attention that it deserves; Sitecore's integration with the ASP.Net Lifecycle events.
Sitecore integrates into the ASP.Net Lifecycle mainly through a HttpModule called the Sitecore Nexus Module (Sitecore.Nexus.Web.HttpModule) that is implemented in the obfuscated assembly Sitecore.Nexus.dll. The job of this DLL is to first validate the Sitecore license file and to bind the execution of Sitecore to the ASP.Net lifecycle events. Without the Nexus module, Sitecore pipelines will not execute and you left with a plane old ASP.Net Application.
As of Sitecore 9.0 the httpRequestBegin pipeline was moved later in the ASP.Net Lifecycle. The side-by-side illustration below shows the change.
In most cases this change is not a big deal but if you have ever tried to integrate Sitecore with 3rd party HTTP Modules (not recommended) and/or OWIN Middleware components you will find that this change has a huge impact. To understand OWIN and how it works in ASP.Net please review https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integrated-pipeline.
The change makes sense when you look at the types of processors that are in the httpRequestBegin. Before the change the user resolver was executing before the Authentication cookie was even looked at.
Sitecore 8.2 httpRequestBegin (Security Principle is null)
Sitecore 9.0 httpRequestBegin (Security Principle is initialized)
I'm writing about this because in my day job I've spent a lot of time integrating Single-Sign-On implementations with Sitecore and I know that most modern tooling just didn't work with Sitecore without a major overhaul to the way they were designed to work. I'm really excited that I can deprecate a lot of complicated logic that never really felt right to begin with, in favor of a more standard implementation.
Subscribe to:
Post Comments
(
Atom
)
It's running now on PostAuthenticateRequest event.
ReplyDelete