asp.net mvc 3 - ¿Debo implementar Glimpse en el sitio de producción?

asp.net-mvc-3

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?

Las cosas que me preocupan incluyen:

• Actuación
• Brechas de seguridad

Answer 1

Comenzando con Glimpse 1.7 hay una forma más genérica de asegurar ~/glimpse.axd con el beneficio adicional de que usa la misma política para todos. Simplemente necesita asegurarse de que su política personalizada también requiera recursos:

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

Observe el | RuntimeEvent.ExecuteResource | RuntimeEvent.ExecuteResource . Ver la parte inferior de: blog.getglimpse.com/2013/12/09/… .

Answer 2

Creo que si no se encuentra la cookie de Glimpse, no carga ni hace nada, por lo que el rendimiento debería 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 una función de administrador, puede hacerlo por rol en lugar de por nombre de usuario.

También puede desactivarlo 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 transformación ahora se vería de la siguiente manera. Intentar establecer el atributo enabled dará un error de configuración en la versión más reciente de Glimpse.

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

Como dice la documentación ...

Glimpse nunca podrá hacer más con una respuesta Http que la especificada en DefaultRuntimePolicy .

Cabe señalar que el único propósito que cumple esta transformación es si desea eliminar la capacidad de usar 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 se debe permitir 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 LocalPolicy que impide que las solicitudes remotas LocalPolicy é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 el atisbo, pero no evitan que el usuario pueda abrir 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 a la GlimpseSecurityPolicy anterior.

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

Answer 3

Yarx tiene razón 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, usó la transformación que proporcionó Yarx, el vislumbre nunca se cargará, incluso si tiene activada la cookie.