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

feat: Extract prototyped data in extractUserData #2247

Merged
merged 2 commits into from
Sep 25, 2019

Conversation

jbloxham
Copy link
Contributor

I have a slightly unusual express server setup in which the client provides their user ID in the req.user field, then a middleware replaces this with the corresponding user entry from a database, thus populating req.user.email and req.user.id. Unfortunately, it turns out that sentry is unable to extract these fields automatically, because they are defined in the prototype of the req.user object, and thus are ignored by hasOwnProperty. Changing this to a simple in operator fixes this issue. I don't see a good reason why hasOwnProperty should be preferred to in here, as the extracted fields are configurable anyways.

I have a slightly unusual express server setup in which the client provides their user ID in the `req.user` field, then a middleware replaces this with the corresponding user entry from a database, thus populating `req.user.email` and `req.user.id`. Unfortunately, it turns out that sentry is unable to extract these fields automatically, because they are defined in the prototype of the `req.user` object, and thus are ignored by `hasOwnProperty`. Changing this to a simple `in` operator fixes this issue. I don't see a good reason why `hasOwnProperty` should be preferred to `in` here, as the extracted fields are configurable anyways.
@kamilogorek
Copy link
Contributor

I don't see a good reason why hasOwnProperty should be preferred to in here, as the extracted fields are configurable anyways.

True. Thanks for the PR.

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

Successfully merging this pull request may close these issues.

None yet

2 participants