Как разрешать запросы в веб-Api?

Я пытаюсь реализовать регулирование запроса с помощью следующего:

Лучший способ реализовать настройку запроса в ASP.NET MVC?

Я вытащил этот код в свое решение и украсил конечную точку контроллера API атрибутом:

[Route("api/dothis/{id}")]
[AcceptVerbs("POST")]
[Throttle(Name = "TestThrottle", Message = "You must wait {n} seconds before accessing this url again.", Seconds = 5)]
[Authorize]
public HttpResponseMessage DoThis(int id) {...}

Это компилируется, но код атрибута не попадает, и дросселирование не работает. Однако я не ошибаюсь. Что мне не хватает?

Ответы

Ответ 1

Кажется, вы запутались в фильтрах действий для ASP.NET MVC-контроллера и фильтров действий для ASP.NET-контроллера Web API. Это 2 совершенно разных класса:

Похоже, что вы показали действие контроллера веб-API (которое объявлено внутри контроллера, полученного из ApiController). Поэтому, если вы хотите применить к нему настраиваемые фильтры, они должны быть получены из System.Web.Http.Filters.ActionFilterAttribute.

Итак, давайте продолжим и адаптируем код для веб-API:

public class ThrottleAttribute : ActionFilterAttribute
{
    /// <summary>
    /// A unique name for this Throttle.
    /// </summary>
    /// <remarks>
    /// We'll be inserting a Cache record based on this name and client IP, e.g. "Name-192.168.0.1"
    /// </remarks>
    public string Name { get; set; }

    /// <summary>
    /// The number of seconds clients must wait before executing this decorated route again.
    /// </summary>
    public int Seconds { get; set; }

    /// <summary>
    /// A text message that will be sent to the client upon throttling.  You can include the token {n} to
    /// show this.Seconds in the message, e.g. "Wait {n} seconds before trying again".
    /// </summary>
    public string Message { get; set; }

    public override void OnActionExecuting(HttpActionContext actionContext)
    {
        var key = string.Concat(Name, "-", GetClientIp(actionContext.Request));
        var allowExecute = false;

        if (HttpRuntime.Cache[key] == null)
        {
            HttpRuntime.Cache.Add(key,
                true, // is this the smallest data we can have?
                null, // no dependencies
                DateTime.Now.AddSeconds(Seconds), // absolute expiration
                Cache.NoSlidingExpiration,
                CacheItemPriority.Low,
                null); // no callback

            allowExecute = true;
        }

        if (!allowExecute)
        {
            if (string.IsNullOrEmpty(Message))
            {
                Message = "You may only perform this action every {n} seconds.";
            }

            actionContext.Response = actionContext.Request.CreateResponse(
                HttpStatusCode.Conflict, 
                Message.Replace("{n}", Seconds.ToString())
            );
        }
    }
}

где метод GetClientIp исходит из this post.

Теперь вы можете использовать этот атрибут в действии контроллера веб-API.

Ответ 2

Предлагаемое решение неточно. Для этого существует не менее 5 причин.

  • Кэш не обеспечивает блокировку управления между различными потоками, поэтому несколько запросов могут одновременно обрабатывать дополнительные вызовы, пропуская через дроссель.
  • Фильтр обрабатывается "слишком поздно в игре" в конвейере веб-API, поэтому затрачивается много ресурсов, прежде чем вы решите, что запрос не должен обрабатываться. ДелегированиеHandler следует использовать, потому что его можно настроить для запуска в начале конвейера веб-API и прервать запрос перед выполнением дополнительной работы.
  • Кэш Http - это зависимость, которая может быть недоступна с новыми режимами работы, такими как самообслуживаемые параметры. Лучше избегать этой зависимости.
  • Кэш в приведенном выше примере не гарантирует его выживания между вызовами, поскольку он может быть удален из-за давления памяти, особенно с низким приоритетом.
  • Хотя это не так уж плохо, настройка статуса ответа на "конфликт" не представляется лучшим вариантом. Вместо этого лучше использовать "429 - слишком много запросов".

Есть еще много проблем и скрытых препятствий для решения при реализации дросселирования. Есть свободные варианты с открытым исходным кодом. Например, я рекомендую посмотреть https://throttlewebapi.codeplex.com/.

Ответ 3

WebApiThrottle является настоящим чемпионом в этой области.

Это супер легко интегрировать. Просто добавьте следующее в App_Start\WebApiConfig.cs:

config.MessageHandlers.Add(new ThrottlingHandler()
{
    // Generic rate limit applied to ALL APIs
    Policy = new ThrottlePolicy(perSecond: 1, perMinute: 20, perHour: 200)
    {
        IpThrottling = true,
        ClientThrottling = true,
        EndpointThrottling = true,
        EndpointRules = new Dictionary<string, RateLimits>
        { 
             //Fine tune throttling per specific API here
            { "api/search", new RateLimits { PerSecond = 10, PerMinute = 100, PerHour = 1000 } }
        }
    },
    Repository = new CacheRepository()
});

Он доступен как нуджет с тем же именем.

Ответ 4

Я использую ThrottleAttribute, чтобы ограничить скорость вызова моего API отправки коротких сообщений, но я обнаружил, что он не работает иногда. API может быть вызван много раз, пока логика дроссельной заслонки не работает, наконец, я использую System.Web.Caching.MemoryCache вместо HttpRuntime.Cache, и проблема, похоже, решена.

if (MemoryCache.Default[key] == null)
{
    MemoryCache.Default.Set(key, true, DateTime.Now.AddSeconds(Seconds));
    allowExecute = true;
}

Ответ 5

Дважды проверьте операторы using в вашем фильтре действий. Когда вы используете контроллер API, убедитесь, что вы ссылаетесь на ActionFilterAttribute в System.Web.Http.Filters, а не на System.Web.Mvc.

using System.Web.Http.Filters;

Ответ 6

Мои 2 цента добавляют дополнительную информацию для "ключа" о запросе информации о параметрах, так что с одного и того же IP-адреса разрешен другой параметр.

key = Name + clientIP + actionContext.ActionArguments.Values.ToString()

Кроме того, моя небольшая забота о "clientIP", возможно ли, что два разных пользователя используют один и тот же ISP, имеет тот же "clientIP"? Если да, то один клиент меня задушит неправильно.