|
Professor Seleznov
|
Как "красивый" Ruby-синтаксис украл request из Grape и поломал нам Rate Limiting
Решили мы как-то добавить Rate Limits заголовки к SubscriptionRequiredError ошибкам, чтобы фронт (приложение для подсчета калорий MealUp) понимал, какие именно лимиты и насколько пользователь превысил. Для этого мы стали рендерить эту ошибку с расчётом лимитов для конкретного пользователя - current_user. Перехватывали мы ошибку стандартно:
mealup/app/api/v1/api.rb:
module V1
class API < Grape::API
...
rescue_from SubscriptionRequiredError, with: :render_error
...
helpers V1::Helpers::ResponseHelpers
...
mealup/app/api/v1/helpers/response_helpers.rb:
module V1
module Helpers
module ResponseHelpers
...
def render_error(error)
error = serialize_error(error)
error!({ error:, with: error_entity(error) }, error.try(:http_status) || 403)
end
def serialize_error(error)
case error
...
when SubscriptionRequiredError
assign_rate_limit_headers(current_user, error.limit_key) # <- Вот что добавилось
error
...
end
...
Казалось бы, что может пойти не так? А вот выясняется, что нету там current_user-а. Более того - там нет даже объекта request, из которого через заголовки мы этого current_user-а и ищем. "Как в апи при обработке запроса может отсутствовать объект запроса", - спросите вы? "Никак", - ответил бы я. И был бы неправ.
Посмотрим поближе, что происходит с DSL Grape, и куда девается наш request. В проекте у нас используется gem 'grape-swagger', который под капотом использует grape 2.2.0. Поэтому обсуждаем эту версию.
:rescue_from метод определяется в Grape::DSL::RequestResponse (lib/grape/dsl/request_response.rb). Там Grape собирает найденные обработчики ошибок и записывает их в InheritableSetting, после чего они будут переданы в Grape::Middleware::Error при инициализации как :options. Записываются они примерно так:
options[:rescue_handlers]
=> {
ActiveRecord::RecordNotFound=>:render_not_found_error,
SubscriptionRequiredError=>:render_error,
Telegram::InvalidSchemeError=>:render_error
}
Когда понадобится обработать ту или иную ошибку, за это возьмется метод Grape::Middleware::Error#run_rescue_handler.
def run_rescue_handler(handler, error, endpoint)
if handler.instance_of?(Symbol)
raise NoMethodError, "undefined method '#{handler}'" unless respond_to?(handler)
handler = public_method(handler) # <- Здесь символ :render_error превратится в объект класса Method
end
...
Здесь handler из символа :render_error превращается в объект класса Method:
handler
=> #(V1::Helpers::ResponseHelpers)#render_error(error) .../mealup/app/api/v1/helpers/response_helpers.rb:59>
чуть позже в том же run_rescue_handler будет вызван endpoint.instance_exec(error, &handler), и код возвращается из гема в наш helper, но уже без request и без current_user.
А что если мы чуть пожертвуем красотой в api.rb, и вместо одной строки, будем отлавливать ошибку на трех?
# rescue_from SubscriptionRequiredError, with: :render_error
rescue_from SubscriptionRequiredError do |e|
render_error(e)
end
На первый взгляд - то же самое. Но вот где кроется отличие:
options[:rescue_handlers]
=> {
ActiveRecord::RecordNotFound=>:render_not_found_error,
SubscriptionRequiredError=>#,
Telegram::InvalidSchemeError=>:render_error
}
теперь в методе run_rescue_handler grape не будет подменять наш handler и вызывать public_method(handler). Он возьмет наш блок или лямбду, смотря, как вы определили rescue_from обработчик, и точно также передаст его в endpoint: endpoint.instance_exec(error, &handler). И уже в этом случае мы возвращаемся из гема в наш helper и с объектом request, и с current_user.
Почему же так происходит?
Это уже не особенность Grape, а поведение самого Ruby. Дело в instance_exec, Method, Proc и в том, как они работают с self, от которого зависит, какие методы и данные доступны в момент выполнения. Объект Method - это метод, привязанный к конкретному receiver-у, какому-то объекту. В нем - self всегда будет равным этому объекту. Proc, block и lambda - более гибки в этом вопросе, и выполняются с self, заданным в момент вызова.
Чтобы понять, почему Method теряет контекст, а лямбда — нет, давайте посмотрим на простенький пример. Определим пару классов:
class Middleware
def greet
puts "self is: #{self.class}"
puts "request: #{respond_to?(:request) ? request.inspect : 'NO METHOD request'}"
end
end
class Endpoint
attr_reader :request
def initialize
@request = "I am the request object"
end
def greet
puts "self is: #{self.class}"
puts "request: #{respond_to?(:request) ? request.inspect : 'NO METHOD request'}"
end
end
И создадим их экземпляры:
middleware = Middleware.new
endpoint = Endpoint.new
Теперь если мы возьмем метод :greet из middleware и применим его в контексте endpoint, как вы думаете, что будет? Увидит ли он @request?
irb(main):123> handler = middleware.public_method(:greet)
#
irb(main):123> endpoint.instance_exec(&handler)
self is: Middleware
request: NO METHOD request
=> nil
А если handler будет лямбдой?
irb(main):125> handler = -> { puts "self is: #{self.class}"; puts "request: #{request.inspect}" }
=> #
endpoint.instance_exec(&handler)
self is: Endpoint
request: "I am the request object"
=> nil
То же самое происходит и в Grape. Когда мы вызываем endpoint.instance_exec(error, &handler), мы вызываем handler в контексте экземпляра Grape::Endpoint:
gems/grape-2.2.0/lib/grape/endpoint.rb:
...
module Grape
# An Endpoint is the proxy scope in which all routing
# blocks are executed. In other words, any methods
# on the instance level of this class may be called
# from inside a `get`, `post`, etc.
class Endpoint
include Grape::DSL::Settings
include Grape::DSL::InsideRoute
attr_accessor :block, :source, :options
attr_reader :env, :request, :headers, :params # <- метод request здесь присутствует
...
Но в случае с Method это не срабатывает. Если мы сами определили этот handler из Grape::Middleware::Error (на самом деле, из middleware-цепочки proxy-объекта Grape), то атрибуты Grape::Endpoint, такие как request, для него уже недоступны. В отличие от этого, Proc выполняется с self, равным endpoint, поэтому объект request там будет доступен. Это, кстати, можно проверить даже из хелпера в MealUp:
mealup/app/api/v1/helpers/response_helpers.rb:
def serialize_error(error)
...
when SubscriptionRequiredError
debugger # <- Ставим debugger перед тем местом, где должна произойти ошибка
assign_rate_limit_headers(current_user, error.limit_key)
error
...
end
Если :rescue_from определен с символом:
70: when SubscriptionRequiredError
71: debugger
=> 72: assign_rate_limit_headers(current_user, error.limit_key)
73: error
74: else
75: error
76: end
(byebug) Grape::Middleware::Error === self
true
(byebug) Grape::Endpoint === self
false
Если :rescue_from определен с лямбдой или блоком:
70: when SubscriptionRequiredError
71: debugger
=> 72: assign_rate_limit_headers(current_user, error.limit_key)
73: error
74: else
75: error
76: end
(byebug) Grape::Middleware::Error === self
false
(byebug) Grape::Endpoint === self
true
Проще говоря: Proc берёт self из места вызова, а Method — из своего receiver’а
Почему мы любим Ruby
Что ж, мы нашли способ пофиксить проблему. Тесты проходят, headers отбиваются на фронт и с успешным ответом, и с ошибкой. Наши пользователи смогут считать калории бесплатно, и знать, в какой момент им потребуется подписка. Но ТРИ строки, когда можно написать одну? Для любого Ruby разработчика это звучит как вызов. Поэтому, финальный фикс, который пошел в прод выглядит так:
mealup/app/api/v1/api.rb:
rescue_from SubscriptionRequiredError, with: ->(e) { render_error(e) }
Выводы
1. В Grape rescue_from с символом (with: :render_error) превращает обработчик в экземпляр Method, который жёстко привязан к объекту из middleware-цепочки и выполняется вне контекста Grape::Endpoint, из-за чего теряет доступ к request.
2. rescue_from с блоком или лямбдой сохраняет контекст Grape::Endpoint благодаря гибкости Proc.
3. Если ваш обработчик ошибки обращается к request, params, current_user или другим методам Grape::Endpoint — всегда используйте лямбду или блок.
4. Красивый синтаксис не всегда правильный. Иногда за красотой скрывается боль многочасового дебага. (Но Ruby - все равно классный).-Источник
|
