Protecting a QA site from anonymous access

Question

I'm trying to protect my QA site from anonymous users coming to it. I tried using basic authentication, which works for the front-end, but because it changes the authentication type to "Windows" it knocks out the admin area (trying to log in just bounces you back to the login screen again).

My site has Sitecore authentication for a subset of data, so I can't just slap a forms authentication on the whole thing (besides it adding a layer of coding that's not needed in production). IIS also doesn't allow for both forms and basic authentication to function together...I tried it and it seemed to favor forms and ignore basic.

I want to make it so users have to enter a simple username/password to see anything of the site (front end or Sitecore shell area), but not knock out the front-end login functionality or the Sitecore login functionality.

Answer 1

Not sure this is what your looking for, but if you add:

requireLogin="true"

To your site definition, Sitecore will not allow unauthorized users to view the site. I'm not sure how it will behave without a loginpage.

Answer 2

We implemented our own login page with an HTTP module to protect the site. We enable this in each of our Site configs (so that we can have some running in QA only before they are live) this is implemented as follows:

 public class QAModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.BeginRequest += ProcessRequest;
        }

        public void Dispose()
        {
            // part of the IHttpModule interface, no implementation required
        }

        private static void ProcessRequest(object sender, EventArgs e)
        {
            var request = HttpContext.Current.Request;
            new SiteQARequestLogic(request, Redirect, SiteQAIsEnabled).Redirect();
        }

        private static void Redirect(string url)
        {
            HttpContext.Current.Response.Redirect(url, false);
        }

        private static bool SiteQAIsEnabled()
        {
            //get value from config here
        }

        public class SiteQARequestLogic
        {
          //check paths and if cookie exists here and return if to re-direct or not (return: true/false)
        }
    }

This a added like so:

<system.webServer>
    <modules>
      <add name="SiteAuth" type="My.Extensions.SiteQAModule, My.Extensions" />
    </modules>
<system.webServer>

We also have a login page that sets a cookie and the http module skips over this if the user is logged in:

public partial class SiteQALogin : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {

    }

    protected void Login_Click(object sender, EventArgs e)
    {
        //check password and set cookie here if correct
    }

    private static bool CheckPassword(string username, string password)
    {
        //check password here against config
    }
}

This allows us a lot more control over the logic of which pages are protected and which are not and on which sites.

Answer 3

The answer turns out to be using the Windows authentication setting in IIS. This doesn't change the web.config, so you have access to the Sitecore shell still if your web.config authentication is set to "None" (the default it ships with); if you set it to "Forms" then you may hit a conflict.

If you're using TDS in this configuration, you'll need to set the "_DEV" folder to use "anonymous" access instead for just that folder, or you won't be able to sync up.

One caveat is you won't be able to use the site locally without making some registry changes. I can detail those if someone needs them, but for our QA servers, we don't need the site accessible on the server itself, we can check it off the VM.