Should I deploy Glimpse to the production site?

Question

I recently added the Glimpse Debugger package to my project. This added a reference to the Glimpse dll, and modified some Web.Config.

I like my project as much the same as possible on my development and production environment.

So is it save/wise to deploy Glimpse to my production site, or should I create a different project (or create branch from my csproj file) to keep it only locally?

Stuff that I'm worried about include:

• Performance
• Security breaches

Bulldog

As an update to this, we released a new updaet a little while ago, which allows you to lock things down using even more custom logic - blog.getglimpse.com/2013/12/09/… – Annadiana

Answer 1

I believe if the cookie for Glimpse is not found it doesn't load or do anything so performance should be negligible. Security wise you can just set a user restriction in the web.config for the location of the glimpse path.

<location path="Glimpse.axd" >
    <system.web>
        <authorization>
            <allow users="Administrator" />
            <deny users="*" />
        </authorization>
    </system.web>
</location>

Or if there is an administrator role you could do it by role instead of user name.

You can also switch it off if you don't want to rely on just the presence of the cookie. This easily achieved through web.config transforms, I haven't tested the markup yet but something like this should work.

<glimpse enabled="false" xdt:Transform="SetAttributes">
</glimpse>

---

UPDATE: Glimpse has seen some changes recently and (since 1.0 I believe?) the transform would now look as follows. Trying to set the enabled attribute will give a configuration error in the most recent version of Glimpse.

<glimpse defaultRuntimePolicy="Off" xdt:Transform="SetAttributes">
</glimpse>

As the documentation puts it...

Glimpse will never be allowed to do more with a Http response than is specified in DefaultRuntimePolicy.

It should be noted that the only purpose this transform serves, is if you want to remove the ability to use Glimpse as part of your deployment process. If you want to conditionally disable it based on other criteria such as remote requests or authorization check, these are better done via policies. Glimpse operates off of a series of policies now (all based off of IRuntimePolicy), designed to help determine when glimpse should be allowed to do it's thing. In fact once Glimpse is installed, if you navigate to glimpse.axd, at the bottom of that page, you'll see a list of policies that are currently enabled. Such as the LocalPolicy that prevents it from being accessed by remote requests (configurably, any policy can be ignored via the web.config to allow remote requests) http://getglimpse.com/Help/Configuration. They also have a sample class called GlimpseSecurityPolicy that is included when you install Glimpse using Nuget, which you can use to add a authorization restrictions.

public class GlimpseSecurityPolicy:IRuntimePolicy
{
    public RuntimePolicy Execute(IRuntimePolicyContext policyContext)
    {
        // You can perform a check like the one below to control Glimpse's permissions within your application.
        // More information about RuntimePolicies can be found at http://getglimpse.com/Help/Custom-Runtime-Policy
        var httpContext = policyContext.GetHttpContext();
        if (httpContext.User != null && !httpContext.User.IsInRole("Glimpse")) //Once glimpse is turned on, you have to be a member of this Role to see the Glimpse Panel.
        {
            return RuntimePolicy.Off;
        }

        return RuntimePolicy.On;
    }

    public RuntimeEvent ExecuteOn
    {
        get { return RuntimeEvent.EndRequest; }
    }
}

Now the policies are used to determine when glimpse should run, but they don't prevent the user from being able to bring up the glimpse.axd page. The cookie can still be enabled from what from what I can tell, but the cookie is meaningless if glimpse refuses to run in spite of the cookie being present. That being said It's still advisable to wrap the glimpse.axd page in an authorization check using the location tag in your web.config. Note that this is in addition to the GlimpseSecurityPolicy above.

<location path="glimpse.axd">
  <system.web>
    <authorization>
      <allow roles="Glimpse" />
      <deny users="*" />
    </authorization>
  </system.web>
</location>

Quite

Hi Yarx, could you tell me where in the web.config this line goes? <glimpse on="false" xdt:Transform="SetAttributes"> </glimpse> – Unprejudiced

VS2010 has the ability to create what it calls "Transform Files" for your web.config file. And these are ran on your web.config file at build time in order to modify it in preparation for your target deployment based off of the the build configuration used. For example, if you are in release mode, it applies transformations from the web.release.config file. To get these files simply right click on web.config and choose Add Config Transforms There are many tutorials that explain how these files work, and the syntax to use. msdn.microsoft.com/en-us/library/dd465326.aspx – Quite

Note that Glimpse/Config has been replaced with Glimpse.axd. – Whittle

@Yarx I don't know if the attribute was (On) before but it's (enabled) in 0.86, so the transformation would be: <glimpse enabled="false" xdt:Transform="SetAttributes"> – Membrane

@Yarx A clarification is in place here. The config file transformation isn't done when compiling but when publishing. (which makes the functionality useless in scenarios with build machines) – Mystagogue

You're right, by default it's applied during publish, not compiling. I'm assuming there must be options for applying them with build machines. A quick Google search yielded me this result. While the article implies it's steps are intended for TFS, they seem generic enough to adapt to other environments that use MSBuild. I've not had to configure a build machine so I can't speak from experience on that front. – Quite

Is there another way to prevent access to axd. We are not using .net authorization. ty – Undertrick

Yes, see the following blog post - blog.getglimpse.com/2013/12/09/… – Annadiana

That's the same thing I mention in the middle of the post regarding IRuntimePolicy. – Quite

Answer 2

Yarx is right on pretty much all fronts.

From a security perspective you could lock down the path using the method described. Only thing is, there are more URL end points that glimpse uses, so the rule would need to be something like *Glimpse/* (where * says that anything can come before it and anything can come after it). Once this is in place, glimpse should be pretty locked down.

Also, if in the config, you used the transform that Yarx provided, glimpse will never load, even if you have the cookie turned on.

Annadiana

*Glimpse/* is not allowed in the path attribute <location> path attribute must be a relative virtual path. It cannot contain any of '?' ':' '\' '*' '"' '<' '>' or '|'. so where should I put it? Thanks – Debar

Answer 3

Starting with Glimpse 1.7 there is a more generic way to secure ~/glimpse.axd with the additional benefit that you use the same policy for all. You simply need to make sure that your custom policy is called for resources too:

 public RuntimeEvent ExecuteOn
 {
     // The bit flag that signals to Glimpse that it should run on either event
     get { return RuntimeEvent.Endrequest | RuntimeEvent.ExecuteResource; }
 }

Notice the | RuntimeEvent.ExecuteResource. See bottom of: Securing Glimpse.axd the way forward.

Alkene