Dois-je déployer Glimpse sur le site de production?

J’ai récemment ajouté le package Glimpse Debugger à mon projet. Cela a ajouté une référence à la DLL Glimpse, et modifié certains Web.Config.

J’aime mon projet autant que possible sur mon environnement de développement et de production.

Alors, est-il préférable de déployer Glimpse sur mon site de production ou dois-je créer un projet différent (ou créer une twig à partir de mon fichier csproj) pour le conserver uniquement localement?

Les choses qui m’inquiètent comprennent:

  • Performance
  • Failles de sécurité

Je crois que si le cookie pour Glimpse n’est pas trouvé, il ne se charge pas ou ne fait rien pour que les performances soient négligeables. En termes de sécurité, vous pouvez simplement définir une ressortingction utilisateur dans le fichier web.config pour l’emplacement du chemin de visualisation.

        

Ou, s’il existe un rôle d’administrateur, vous pouvez le faire par rôle plutôt que par nom d’utilisateur.

Vous pouvez également le désactiver si vous ne souhaitez pas vous fier uniquement à la présence du cookie. Cela se fait facilement grâce aux transformations web.config, je n’ai pas encore testé le balisage, mais quelque chose comme ça devrait fonctionner.

   

MISE À JOUR : Glimpse a vu quelques changements récemment et (depuis la version 1.0, je crois?), La transformation devrait maintenant ressembler à ceci. Essayer de définir l’atsortingbut enabled donnera une erreur de configuration dans la version la plus récente de Glimpse.

   

Comme l’indique la documentation …

Glimpse ne sera jamais autorisé à faire plus avec une réponse DefaultRuntimePolicy que celle spécifiée dans DefaultRuntimePolicy .

Il convient de noter que le seul but de cette transformation est de supprimer la possibilité d’utiliser Glimpse dans le cadre de votre processus de déploiement. Si vous souhaitez le désactiver de manière conditionnelle en fonction d’autres critères, tels que les demandes à distance ou le contrôle des permissions, il est préférable de le faire via des stratégies. Glimpse opère à partir d’une série de politiques maintenant (toutes basées sur IRuntimePolicy ), conçues pour aider à déterminer quand un aperçu doit être autorisé à faire quelque chose. En fait, une fois Glimpse installé, si vous accédez à glimpse.axd, en bas de cette page, vous verrez une liste des stratégies actuellement activées. Comme la LocalPolicy qui l’empêche d’être consultée par les requêtes distantes (de manière configurable, toute politique peut être ignorée via le fichier web.config pour autoriser les requêtes distantes) http://getglimpse.com/Help/Configuration . Ils ont également un exemple de classe appelé GlimpseSecurityPolicy qui est inclus lorsque vous installez Glimpse à l’aide de Nuget, que vous pouvez utiliser pour append des ressortingctions d’autorisation.

 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 politiques sont utilisées pour déterminer quand aperçu doit s’exécuter, mais elles n’empêchent pas l’utilisateur de pouvoir afficher la page glimpse.axd. Le cookie peut toujours être activé à partir de ce que je peux dire, mais le cookie n’a pas de sens si un aperçu refuse de fonctionner malgré la présence du cookie. Cela étant dit, il est toujours conseillé d’emballer la page glimpse.axd dans une vérification d’autorisation à l’aide de la balise location dans votre fichier web.config. Notez que ceci est en plus de la politique GlimpseSecurityPolicy ci-dessus.

         

Yarx a raison sur presque tous les fronts.

Du sharepoint vue de la sécurité, vous pouvez verrouiller le chemin en utilisant la méthode décrite. La seule chose est, il y a plus de points de terminaison d’URL utilisés par aperçu, donc la règle devrait être quelque chose comme *Glimpse/* (où * indique que tout peut venir avant et que tout peut venir après). Une fois que cela est en place, aperçu devrait être assez verrouillé.

De plus, si dans la configuration, vous avez utilisé la transformation fournie par Yarx, aperçu ne se chargera jamais, même si vous avez activé le cookie.

À partir de Glimpse 1.7, il existe un moyen plus générique de sécuriser ~/glimpse.axd avec l’avantage supplémentaire d’utiliser la même stratégie pour tous. Vous devez simplement vous assurer que votre stratégie personnalisée est également appelée pour des ressources:

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

Notez le | RuntimeEvent.ExecuteResource | RuntimeEvent.ExecuteResource . Voir en bas de: Sécurisation de Glimpse.axd la voie à suivre .