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

Ответ 1

Я считаю, что если 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>

UPDATE: Glimpse недавно изменил некоторые изменения и (начиная с версии 1.0)? Теперь преобразование будет выглядеть следующим образом. Попытка установить атрибут enabled приведет к ошибке конфигурации в самой последней версии Glimpse.

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

Как говорится в документации...

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

Следует отметить, что единственной целью, которой служит это преобразование, является то, что вы хотите удалить возможность использования Glimpse как часть процесса развертывания. Если вы хотите условно отключить его на основе других критериев, таких как удаленные запросы или проверка авторизации, это лучше сделать с помощью политик. Glimpse теперь отключается от серии политик (все основаны на IRuntimePolicy), предназначенные для определения того, когда проблематика должна позволять делать это. Фактически после установки 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 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. Печенье по-прежнему можно активировать из того, что я могу сказать, но cookie не имеет смысла, если проблеск отказывается бежать, несмотря на присутствие файла cookie. Это говорит, что по-прежнему рекомендуется обернуть страницу glimpse.axd в проверку авторизации с помощью тега location в вашем web.config. Обратите внимание, что это в дополнение к GlimpseSecurityPolicy выше.

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

Ответ 2

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

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

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

Ответ 3

Начиная с 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 вперед.