Here's the situation. You are about to implement a password protected area on your website. Let's assume that the general site structure looks like this
Pages below General and Products are accessible to everyone, whereas pages under Members should only be visible to authenticated/logged in members. I will first briefly outline the steps required to get this problem implemented using ASP.NET. Later on, I'll move onto it's equivalent Sitecore Solution.
- Implement Forms Authentication and set login url in the web.config.
- Implement Login control and decide where to retrieve and store login credentials (in web.config or database)
- In the web.config, add a Location Path pointing to the Members folder (Deny anonymous , allow authenticated users )
- This is all about it really...(as far as I remember..) ...
In Sitecore, it's a different ball game.
In addition to adding the loginURL to the form authentication section (important if you use the loginview control to show the login page), you will need to add the "loginPage" attribute to the site which is defined by your extranet domain (normally, it's called "website" )
<site name="website" virtualFolder="/" physicalFolder="/"
The LoginPage attribute is not something new here..It has always been there..(e.g. the shell website has already a loginPage set), but i did not know what was its purpose . Thanks to Chris Wojciech, I've discovered how to use this existing functionality in the web application.
The addition of Location path in the asp.net-only model is analogous to denying read access to the Members folder (+descendants) in Sitecore.
Once you perform a site publish, you can see the effects straight away.
If you've already signed in, you will be able to view /Members/View My Account.aspx.
If you're an anonymous user and access /Members/View My Account.aspx, you will be presented with a default page that Sitecore serves in case access is denied due to security privileges.
Quick Fix :
The page served in this case is called noaccess.aspx. The good thing is that this can be altered by changing the value of the "NoAccessUrl" attribute in the web.config.
If we set "NoAccessUrl" to "/General/Login.aspx", we end up in this situation
The nag in the above quick fix is that sitecore internally adds 3 QueryStrings to the url ( item, user and site). If we compare this to the normal ASP.NET solution, we would have ended up with only 1 querystring, which is the ReturnUrl. Our goal is to follow the asp.net solution as close as possible. This is where Chris comes in..
Rolling out your own Security Resolver
Chris extended the HttpRequestProcessor class in order to intercept the request ,check if the user requesting the sitecore item has appropriate rights. If that is not the case, the user is redirected to the login page, with the appropriate ReturnUrl QueryString. Please go check the code out on his blog at http://blog.wojciech.org/?p=64
The processor should then be plugged in the web.config, before the definition of the ExecuteRequest processor.
<processor type="Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel"/>
<processor type="Sitecore.Pipelines.HttpRequest.LayoutResolver, Sitecore.Kernel"/>
<processor type="MyWebApp.Pipelines.MyOwnSecurityResolver, MyWebApp"/>
<processor type="Sitecore.Pipelines.HttpRequest.ExecuteRequest, Sitecore.Kernel"/>
If you now try to access a protected page as an anonymous user, you'll end up on the login page (but this time, the ReturnUrl parameter has replaced the 3 built-in sitecore url parameters)