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

Set warden scope on user data #777

Closed
javierjulio opened this issue Apr 19, 2023 · 2 comments · Fixed by #821
Closed

Set warden scope on user data #777

javierjulio opened this issue Apr 19, 2023 · 2 comments · Fixed by #821
Labels
released This feature/bug fix has been released

Comments

@javierjulio
Copy link
Contributor

javierjulio commented Apr 19, 2023

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 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.

user_object = env["warden"].user({:scope => best_scope, :run_callbacks => false}) rescue nil
if user_object
# Build the user info for this scope
COMMON_USER_FIELDS.each do |field|
user[field] = user_object.send(field) if user_object.respond_to?(field)
end

So if we had an id of 2, we wouldn't know if it's a User or AdminUser without the warden scope.

Describe the solution you'd like

Include a scope key in the user 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 of event.user[:scope], for example:

puts event.user[:id], event.user[:scope]
> 2
> :admin_user

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?

@johnkiely1
Copy link
Member

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.

@johnkiely1 johnkiely1 added feature request Request for a new feature backlog We hope to fix this feature/bug in the future labels Apr 19, 2023
@RobertoSmartBear
Copy link

This issue is closed by the release of bugsnag-ruby v6.27.0 on 23-05-2024.

@RobertoSmartBear RobertoSmartBear added released This feature/bug fix has been released and removed feature request Request for a new feature backlog We hope to fix this feature/bug in the future labels May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released This feature/bug fix has been released
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants