You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had removed any user PII from our Bugsnag integration in a large Rails app but we noticed that the default user tab data may still get set (with clear user data) when our before_bugsnag_notify controller method wouldn't apply, e.g. ActionController::InvalidAuthenticityToken error.
While we can remove the user PII entirely, we'd rather just include the id and a link to our admin for that user, just as we do with our current before_bugsnag_notify controller method concern. The issue is that we have User and AdminUser models using Devise and with Bugsnag's WardenUser middleware it does not provide the warden scope.
Hi @javierjulio, sounds like a reasonable idea to us, so we've added a task to the backlog to get this added in the future. We will let you know of updates here.
Description
We had removed any user PII from our Bugsnag integration in a large Rails app but we noticed that the default
user
tab data may still get set (with clear user data) when ourbefore_bugsnag_notify
controller method wouldn't apply, e.g.ActionController::InvalidAuthenticityToken
error.While we can remove the user PII entirely, we'd rather just include the
id
and a link to our admin for that user, just as we do with our currentbefore_bugsnag_notify
controller method concern. The issue is that we haveUser
andAdminUser
models using Devise and with Bugsnag'sWardenUser
middleware it does not provide the warden scope.bugsnag-ruby/lib/bugsnag/middleware/warden_user.rb
Lines 25 to 30 in e5afde5
So if we had an
id
of 2, we wouldn't know if it's aUser
orAdminUser
without the warden scope.Describe the solution you'd like
Include a
scope
key in theuser
object with the warden scope value so its available through the event user data documented in: https://docs.bugsnag.com/platforms/ruby/rails/customizing-error-reports/#user as part ofevent.user[:scope]
, for example:With this new key, we could use that in an on-error callback https://docs.bugsnag.com/platforms/ruby/rails/customizing-error-reports/#on-error-callbacks in our Bugsnag configuration vs having in each controller (through a concern).
On a related note, are methods like
current_user
available from an on-error callback?The text was updated successfully, but these errors were encountered: