[Proposal] Using events to broadcast ReCaptcha response
wenderjean opened this issue · comments
Hey guys,
I was recently moving our applications from ReCaptcha V2 to V3 and I got some issues dealing with the gem, more specifically on instrumentation side, I mean, I wasn't able to instrument Google's response that's an important feature to plot errors considering we're talking about an invisible behavior on our platform.
I spent some time thinking about a good way to get around that problem and what I did was basically fork the repository and add an event emitter after we receive Google's response.
# frozen_string_literal: true
module Recaptcha
class Instrumentation
CHANNEL = 'Recaptcha::API::Response'
def self.report(payload = {})
ActiveSupport::Notifications.instrument(CHANNEL, payload)
end
def self.subscribe(&block)
ActiveSupport::Notifications.subscribe(CHANNEL) do |*args|
event = ActiveSupport::Notifications::Event.new(*args)
yield event if block_given?
end
end
end
end# lib/recaptcha
reply = api_verification(verify_hash, timeout: options[:timeout])
Instrumentation.report(
{ ... }
)It is a solution that's helping us a lot since we're now able to listen to those events and plot them on our LOG manager platform.
I'd like to propose to incorporate a solution like that to the code itself to allow us to avoid maintain a different repository. Initially, I used ActiveSupport::Notifications considering we're dealing with a Rails repository but we could attach a new dependency like whisper to cover both Rails and Sinatra use cases, I could work on that.
What do you guys think?
I'd prefer if the recaptcha had an option to return the full reply and then end-users can do whatever they want with it
I considered the possibility to make the method return a result object instead of true|false, It would require us to break the current behavior and bump a major version but I agree it would be a great option.
Cool, I'll work to create a PR to allow us to visualize it better.
5.5.0 has recaptcha_reply controller method