Dois-je déployer aperçu sur le site de production ?

Question

J'ai récemment ajouté un Aperçu Débogueur paquet à mon projet. Cet ajout d'une référence à l'Aperçu de la dll, et la modification de certains Web.Config.

J'aime mon projet autant les mêmes que possible sur mon développement et l'environnement de production.

Ainsi en est-il enregistrer/sage pour déployer Aperçu de mon site de production, ou devrais-je créer un autre projet (ou de la création d'une branche de mon fichier csproj) afin de la garder seulement à l'échelle locale?

Choses que je suis inquiet, mentionnons les suivants:

• Performance
• Les violations de la sécurité

Answer 1

Je crois que si le cookie pour l'Aperçu n'est pas trouvé, il n'a pas de charger ou de faire quoi que ce soit, la performance devrait être négligeable. Sage de la sécurité, vous pouvez simplement mettre un utilisateur de restriction dans le web.config pour l'emplacement de l'aperçu chemin.

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

Ou si il y a un rôle d'administrateur, vous pourriez le faire par rôle à la place du nom d'utilisateur.

Vous pouvez également le désactiver si vous ne voulez pas compter sur la présence du cookie. Ce facilement atteint par le biais de web.config transforme, je n'ai pas testé le balisage encore, mais quelque chose comme cela devrait fonctionner.

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

---

Mise à JOUR: Aperçu a vu quelques changements récemment et (depuis la 1.0, je crois?) la transformation serait maintenant se présenter comme suit. En essayant de mettre la enabled attribut donnera une erreur de configuration dans la version la plus récente de l'Aperçu.

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

La documentation met...

Aperçu ne sera jamais permis d'en faire plus avec une réponse Http est que spécifié en DefaultRuntimePolicy.

Il convient de noter que le seul but de cette transformation sert, c'est que si vous voulez supprimer la possibilité d'utiliser Aperçu dans le cadre de votre processus de déploiement. Si vous voulez conditionnellement le désactiver sur la base d'autres critères tels que la distance des demandes d'autorisation ou de vérifier, c'est mieux fait par les politiques. Aperçu fonctionne sur une série de politiques aujourd'hui (tous basés sur le IRuntimePolicy), conçu pour aider à déterminer lors de l'aperçu devraient être autorisés à le faire. En fait une fois le coup d'œil est installé, si vous accédez à l'aperçu.axd, au bas de cette page, vous verrez une liste de stratégies qui sont actuellement activés. Comme l' LocalPolicy qui l'empêche d'être consulté par les demandes à distance (configurably, toute politique peut être ignoré par le web.config pour permettre les demandes à distance) http://getglimpse.com/Help/Configuration. Ils ont aussi un exemple de classe appelé GlimpseSecurityPolicy qui est inclus lorsque vous installez Aperçu à l'aide de Nuget, que vous pouvez utiliser pour ajouter une autorisation de 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; }
    }
}

Maintenant, les stratégies sont utilisées pour déterminer lors de l'aperçu doit s'exécuter, mais ils ne sont pas empêcher l'utilisateur d'être en mesure d'afficher l'aperçu.axd page. Le cookie peut toujours être activé à partir de ce que de ce que je peux dire, mais le cookie est vide de sens si entrevoir refuse de fonctionner malgré le cookie. Cela étant dit, Il est toujours conseillé d'envelopper le coup d'œil.axd page dans une demande d'autorisation à l'aide de l'emplacement de la balise dans votre site web.config. À noter que c'est en plus de la GlimpseSecurityPolicy - dessus.

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

Answer 2

Yarx est à droite sur quasiment tous les fronts.

À partir d'un point de vue de sécurité, vous pouvez verrouiller le chemin à l'aide de la méthode décrite. La seule chose c'est, il y a plus d'URL points finaux aperçu utilise, de sorte que la règle devrait être quelque chose comme *Glimpse/* (où * indique que quelque chose peut venir devant elle et tout ce qui peut venir après elle). Une fois cela en place, aperçu devrait être assez verrouillé.

Aussi, si dans la config, vous avez utilisé de la transformation que Yarx fourni, aperçu ne sera jamais de la charge, même si vous avez le cookie activée.