¿Debo implementar Glimpse en el sitio de producción?

Question

Recientemente agregué el paquete Glimpse Debugger a mi proyecto. Esto agregó una referencia al dll Glimpse y modificó algunos Web.Config.

Me gusta mi proyecto tanto como sea posible en mi entorno de desarrollo y producción.

Entonces, ¿es prudente o no implementar Glimpse en mi sitio de producción, o debería crear un proyecto diferente (o crear una bifurcación desde mi archivo csproj) para mantenerlo solo localmente?

cosas que me preocupa son:

• Rendimiento
• fallos de seguridad

Answer 1

Creo que si no se encuentra la cookie de Glimpse no se carga ni hace nada por lo el rendimiento debe ser insignificante. En lo que respecta a la seguridad, puede establecer una restricción de usuario en el archivo web.config para la ubicación de la ruta vislumbrada.

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

O si hay un rol de administrador, puede hacerlo por rol en lugar de nombre de usuario.

También puede apagarlo si no desea confiar únicamente en la presencia de la cookie. Esto se logra fácilmente a través de las transformaciones de web.config, todavía no he probado el marcado pero algo así debería funcionar.

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

---

ACTUALIZACIÓN: Glimpse ha visto algunos cambios recientemente y (desde 1,0 creo?) La transformada tendrá ahora un aspecto de la siguiente manera. Intentar establecer el atributo enabled dará un error de configuración en la versión más reciente de Glimpse. Nunca se permitirá

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

Como la documentación pone ...

Glimpse que ver más con una respuesta HTTP que es especificado en DefaultRuntimePolicy.

Cabe señalar que el único propósito de esta transformación es si desea eliminar la posibilidad de utilizar Glimpse como parte de su proceso de implementación. Si desea deshabilitarlo de manera condicional en función de otros criterios, como solicitudes remotas o verificación de autorización, es mejor hacerlo a través de políticas. Glimpse opera ahora a partir de una serie de políticas (todas basadas en IRuntimePolicy), diseñadas para ayudar a determinar cuándo debe permitirse que el atisbo lo haga. De hecho, una vez que Glimpse está instalado, si navegas a glimpse.axd, en la parte inferior de esa página, verás una lista de las políticas que están habilitadas actualmente. Como el LocalPolicy que impide que las solicitudes remotas accedan a él (de forma configurable, cualquier política puede ignorarse a través de web.config para permitir solicitudes remotas) http://getglimpse.com/Help/Configuration. También tienen una clase de ejemplo llamada GlimpseSecurityPolicy que se incluye al instalar Glimpse usando Nuget, que puede usar para agregar restricciones de autorización.

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; } 
    } 
} 

Ahora las políticas se utilizan para determinar cuándo se debe ejecutar vistazo, pero que no impiden al usuario de la posibilidad de que aparezca la página glimpse.axd.La cookie aún se puede habilitar a partir de lo que puedo decir, pero la cookie no tiene sentido si el vislumbre se niega a ejecutarse a pesar de que la cookie está presente. Dicho esto, es aconsejable ajustar la página glimpse.axd en una verificación de autorización utilizando la etiqueta de ubicación en su web.config. Tenga en cuenta que esto se suma al anterior GlimpseSecurityPolicy.

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

Answer 2

Yarx está justo en casi todos los frentes.

Desde una perspectiva de seguridad, puede bloquear la ruta utilizando el método descrito. Lo único es que hay más puntos finales de URL que vislumbra, por lo que la regla debería ser algo así como *Glimpse/* (donde * dice que cualquier cosa puede venir antes y cualquier cosa puede venir después). Una vez que esto esté en su lugar, el vislumbre debe estar bastante bloqueado.

Además, si está en la configuración, utilizó la transformación que proporcionó Yarx, la visión nunca se cargará, incluso si tiene activada la cookie.

Answer 3

Comenzando con Glimpse 1.7 hay una manera más genérica de asegurar ~/glimpse.axd con el beneficio adicional de que utiliza la misma política para todos. Usted sólo tendrá que asegurarse de que su política personalizada se llama también por los recursos:

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

Aviso del | RuntimeEvent.ExecuteResource. Ver la parte inferior de: Securing Glimpse.axd the way forward.