Должен ли я развернуть Glimpse на производственной площадке? - PullRequest
Новая
       4

Должен ли я развернуть Glimpse на производственной площадке?

72 голосов
/ 21 апреля 2011

Я недавно добавил пакет Glimpse Debugger в свой проект.Это добавило ссылку на библиотеку Glimpse и изменило некоторые Web.Config.

Мне нравится мой проект настолько же, насколько это возможно в моей среде разработки и производства.целесообразно развернуть Glimpse на моем производственном сайте, или я должен создать другой проект (или создать ветку из моего файла csproj), чтобы сохранить его только локально?1008 *

Производительность Нарушения безопасности

Ответы [ 3 ]

105 голосов
/ 21 апреля 2011

Я считаю, что если cookie для Glimpse не найден, он не загружается и не выполняет никаких действий, поэтому производительность должна быть незначительной.В плане безопасности вы можете просто установить ограничение пользователя в файле web.config для местоположения пути взгляда. 

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

Или, если есть роль администратора, вы можете сделать это по роли, а не по имени пользователя.

Вы также можете отключить его, если не хотите полагаться только на наличие файла cookie.Это легко достигается с помощью преобразований web.config, я еще не тестировал разметку, но что-то вроде этого должно работать. 

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

ОБНОВЛЕНИЕ : Glimpse недавно видел некоторые измененияи (начиная с 1.0, я полагаю?) преобразование теперь будет выглядеть следующим образом.Попытка установить атрибут enabled приведет к ошибке конфигурации в самой последней версии Glimpse. 

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

Как указано в документации ...

Glimpse никогда не будетразрешено делать больше с Http-ответом, чем указано в DefaultRuntimePolicy.

Следует отметить, что единственное назначение, которое выполняет это преобразование, - это если вы хотите удалить возможность использовать Glimpse какчасть вашего процесса развертывания.Если вы хотите условно отключить его на основе других критериев, таких как удаленные запросы или проверка авторизации, это лучше сделать с помощью политик.Glimpse работает на основе ряда политик (основанных на IRuntimePolicy), разработанных, чтобы помочь определить, когда glimpse должно быть разрешено делать это.Фактически, после установки Glimpse, если вы перейдете к glimpse.axd, в нижней части этой страницы вы увидите список политик, которые в настоящее время включены.Например, LocalPolicy, который предотвращает доступ к нему через удаленные запросы (конфигурируемо, любая политика может быть проигнорирована через web.config, чтобы разрешить удаленные запросы) http://getglimpse.com/Help/Configuration. У них также есть пример класса, называемый GlimpseSecurityPolicy, которыйвключается при установке Glimpse с помощью Nuget, который можно использовать для добавления ограничений авторизации. 

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

Теперь политики используются для определения времени запуска glimpse, но они не мешают пользователю бытьвозможность вызвать страницу glimpse.axd.Куки все еще могут быть включены из того, что я могу сказать, но куки не имеет смысла, если glimpse отказывается работать, несмотря на наличие куки.При этом все же рекомендуется обернуть страницу glimpse.axd в проверку авторизации, используя тег location в вашем файле web.config.Обратите внимание, что это в дополнение к GlimpseSecurityPolicy выше. 

<location path="glimpse.axd">
  <system.web>
    <authorization>
      <allow roles="Glimpse" />
      <deny users="*" />
    </authorization>
  </system.web>
</location>
9 голосов
/ 21 апреля 2011

Яркс прав практически на всех фронтах.

С точки зрения безопасности вы можете заблокировать путь, используя описанный метод. Единственное, что есть больше конечных точек URL, которые использует glimpse, поэтому правило должно быть примерно таким: *Glimpse/* (где * говорит, что все может предшествовать этому, а что-либо - после него). Как только это будет сделано, проблеск должен быть довольно заблокирован.

Кроме того, если в конфигурации вы использовали преобразование, предоставленное Yarx, glimpse никогда не загрузится, даже если у вас включен файл cookie.

1 голос
/ 18 апреля 2016

Начиная с Glimpse 1.7, существует более общий способ обеспечения безопасности ~/glimpse.axd с дополнительным преимуществом, заключающимся в том, что вы используете одну и ту же политику для всех. Вам просто нужно убедиться, что ваша пользовательская политика также предназначена для ресурсов: 

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

Обратите внимание на | RuntimeEvent.ExecuteResource. См. В нижней части: Обеспечение безопасности Glimpse.axd путь вперед .

...