Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stripe Signature errors are swallowed #110

Open
jasonkarns opened this issue Apr 4, 2018 · 2 comments
Open

Stripe Signature errors are swallowed #110

jasonkarns opened this issue Apr 4, 2018 · 2 comments

Comments

@jasonkarns
Copy link

https://github.com/integrallis/stripe_event/blob/master/app/controllers/stripe_event/webhook_controller.rb#L10-L13

It's handy that StripeEvent does signature verification of stripe messages and responds appropriately (with :bad_request). However, since StripeEvent catches those exceptions and doesn't re-raise, there isn't any way for us to catch and report on Stripe::SignatureVerificationErrors (like, say to bugsnag or newrelic).

I would like these errors re-raised such that the containing application can handle them as necessary, with our own logging and error reporting.

@rmm5t
Copy link
Member

rmm5t commented Apr 4, 2018

@jasonkarns I don't think these errors can be re-raised. Otherwise, we wouldn't be able to respond with the same :bad_request response.

However, what we might be able to add is a configuration hook mechanism to tie into the error handler so that you can report the error (within your specific application) to tools like bugsnag, rollbar, etc.

🤔 I'll noodle on this. In the meantime, if others have implementation ideas and/or pull-requests in mind, let's start a discussion.

@jasonkarns
Copy link
Author

Could add a configuration option which accepts a Callable (block/proc/object-with-call-method) which accepts the error object. If not provided, the default callable could just be the current log_error method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants