4

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.

  • 1
    This Microsoft article presents a solution in IIS to limit the access to your site whitelisting a specific IP addresses, a range of IP addresses or a specific domain: technet.microsoft.com/en-us/library/cc731598(v=ws.10).aspx – Alessandro Faniuolo Feb 15 '17 at 2:34
  • 1
    I would normally put a QA site behind a VPN login. I would not allow the QA site to be publicly accessible. At least some IP whitelisting should be in place. And if it is public, make sure you have set your robots.txt so Google doesn't crawl it :) – Richard Seal Feb 15 '17 at 2:48
3

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.

  • The site already has a login page, and we're trying to basically shield the entire site, including the Sitecore shell, from people being able to see it. So the login functionality for the site itself is what it is, but we're looking for something to prevent folks from getting to anything on that HTTP address without authenticating. But thanks for the suggestion. :) – Ken McAndrew Feb 17 '17 at 20:57
1

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.