Sollte ich Glimpse auf der Produktionsstätte bereitstellen?

Ich habe kürzlich das Glimpse Debugger-Paket zu meinem Projekt hinzugefügt. Dies fügte einen Verweis auf die Glimpse-DLL hinzu und änderte einige Web.Config.

Ich mag mein Projekt in meiner Entwicklungs- und Produktionsumgebung so gut wie möglich.

Ist es also sicher / sinnvoll, Glimpse auf meinem Produktionsstandort bereitzustellen, oder sollte ich ein anderes Projekt erstellen (oder einen Zweig aus meiner csproj-Datei erstellen), um es nur lokal zu behalten?

Zu den Dingen, über die ich mir Sorgen mache, gehören:

• Performance
• Sicherheitsverstoss

Ich glaube, wenn das Cookie für Glimpse nicht gefunden wird, wird es nicht geladen oder tut nichts, daher sollte die Leistung vernachlässigbar sein. In Bezug auf die Sicherheit können Sie einfach in der web.config eine Benutzereinschränkung für den Speicherort des Blickpfads festlegen.

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

Wenn es eine Administratorrolle gibt, können Sie dies auch nach Rolle anstelle des Benutzernamens tun.

Sie können es auch ausschalten, wenn Sie sich nicht nur auf das Vorhandensein des Cookies verlassen möchten. Dies ist leicht durch web.config-Transformationen zu erreichen. Ich habe das Markup noch nicht getestet, aber so etwas sollte funktionieren.

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

UPDATE : In letzter Zeit wurden einige Änderungen vorgenommen, und (seit 1.0, glaube ich?) Würde die Transformation nun wie folgt aussehen. Der Versuch, das enabledAttribut festzulegen, führt in der neuesten Version von Glimpse zu einem Konfigurationsfehler.

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

Wie die Dokumentation es ausdrückt ...

Glimpse darf mit einer HTTP-Antwort niemals mehr tun, als in angegeben DefaultRuntimePolicy.

Es sollte beachtet werden, dass der einzige Zweck dieser Transformation darin besteht, die Möglichkeit zu entfernen, Glimpse als Teil Ihres Bereitstellungsprozesses zu verwenden. Wenn Sie es aufgrund anderer Kriterien wie Remote-Anforderungen oder Berechtigungsprüfung bedingt deaktivieren möchten, erfolgt dies besser über Richtlinien. Glimpse arbeitet jetzt mit einer Reihe von Richtlinien (alle basieren auf IRuntimePolicy), mit denen bestimmt werden soll, wann Glimpse das tun darf. Wenn Sie nach der Installation von Glimpse zu glimpse.axd navigieren, wird unten auf dieser Seite eine Liste der derzeit aktivierten Richtlinien angezeigt. Zum Beispiel das LocalPolicy, das verhindert, dass Remote-Anforderungen darauf zugreifen (konfigurierbar kann jede Richtlinie über die web.config ignoriert werden, um Remote-Anforderungen zuzulassen). Http://getglimpse.com/Help/Configuration. Sie haben auch eine Beispielklasse namens GlimpseSecurityPolicy, die enthalten ist, wenn Sie Glimpse mit Nuget installieren, mit der Sie Autorisierungsbeschränkungen hinzufügen können.

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

Jetzt werden die Richtlinien verwendet, um zu bestimmen, wann glimpse ausgeführt werden soll, aber sie verhindern nicht, dass der Benutzer die Seite glimpse.axd aufrufen kann. Der Cookie kann nach wie vor aktiviert werden, was ich sagen kann, aber der Cookie ist bedeutungslos, wenn ein Blick trotz des vorhandenen Cookies nicht ausgeführt werden kann. Trotzdem ist es immer noch ratsam, die Seite glimpse.axd mit dem Standort-Tag in Ihrer web.config in eine Autorisierungsprüfung einzuschließen. Beachten Sie, dass dies zusätzlich zu den GlimpseSecurityPolicyoben genannten ist.

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

Yarx hat an fast allen Fronten Recht.

Aus Sicherheitsgründen können Sie den Pfad mit der beschriebenen Methode sperren. Die einzige Sache ist, dass es mehr URL-Endpunkte gibt, die von fluch verwendet werden. Die Regel müsste also ungefähr so ​​lauten *Glimpse/*(wobei * besagt, dass alles davor und alles danach kommen kann). Sobald dies geschehen ist, sollte der Blick ziemlich abgeschlossen sein.

Wenn Sie in der Konfiguration die von Yarx bereitgestellte Transformation verwendet haben, wird ein Blick nie geladen, selbst wenn Sie das Cookie aktiviert haben.

Ab Glimpse 1.7 gibt es eine allgemeinere Möglichkeit, ~/glimpse.axdmit dem zusätzlichen Vorteil zu sichern , dass Sie für alle dieselbe Richtlinie verwenden. Sie müssen lediglich sicherstellen, dass Ihre benutzerdefinierte Richtlinie auch für Ressourcen aufgerufen wird:

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

Beachten Sie die | RuntimeEvent.ExecuteResource. Siehe unten unter: Sichern von Glimpse.axd auf dem Weg nach vorne .