Should I deploy Glimpse to the production site?

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 worri开发者_如何转开发ed about include:

• Performance
• Security breaches

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>

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.

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.