-
Notifications
You must be signed in to change notification settings - Fork 369
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
[APPSEC-9545] Devise integration and automatic user events #2877
Conversation
8e43101
to
764382b
Compare
Codecov Report
@@ Coverage Diff @@
## master #2877 +/- ##
==========================================
- Coverage 98.09% 97.98% -0.11%
==========================================
Files 1268 1274 +6
Lines 70031 70313 +282
Branches 3195 3237 +42
==========================================
+ Hits 68697 68897 +200
- Misses 1334 1416 +82
... and 7 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
7b2c972
to
9f28d75
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK to have this merged as is because it works and would need costly rebasing if it drags along, but several comments need addressing in short order, especially public API things.
Also watch out for conflicts with #2858
@@ -113,6 +114,7 @@ def duration(base = :ns, type = :integer) | |||
'DD_APPSEC_TRACE_RATE_LIMIT' => [:trace_rate_limit, Settings.integer], | |||
'DD_APPSEC_OBFUSCATION_PARAMETER_KEY_REGEXP' => [:obfuscator_key_regex, Settings.string], | |||
'DD_APPSEC_OBFUSCATION_PARAMETER_VALUE_REGEXP' => [:obfuscator_value_regex, Settings.string], | |||
'DD_APPSEC_AUTOMATED_USER_EVENTS_TRACKING' => [:automated_track_user_events, Settings.string], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not too fond of that naming. Is DD_APPSEC_AUTOMATED_USER_EVENTS_TRACKING
a specified env var?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes is part of the RFC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK for the env var, although a bit sad.
Indeed I feel like it should probably align with auto instrumentation, e.g:
DD_APPSEC_USER_TRACKING_AUTO_INSTRUMENT
And then overall, I'm thinking we might want a better structure for the code configuration API.
Notably setting something to disabled
rubs me the wrong way because of the double negative:
automated_track_user_events_mode == Patcher::DISABLED_MODE
I feel it should look something like:
c.appsec.user_tracking.enabled = false
c.appsec.user_tracking.enabled = true
c.appsec.user_tracking.enabled = :safe
c.appsec.user_tracking.enabled = :extended
or even this since auto instrumenting being enabled and operation mode are in fact orthogonal:
c.appsec.user_tracking.enabled = false # default?
c.appsec.user_tracking.enabled = true
# or
c.appsec.user_tracking.auto_instrument = false # default?
c.appsec.user_tracking.auto_instrument = true
# and the reporting mode being separate
c.appsec.user_tracking.mode = :safe
c.appsec.user_tracking.mode = :extended
Also, also I don't understand how one is "safe" and the other "extended", somewhat implying "extended" is not "safe" (when IIUC it's actually safer WRT user naming in some ways since "extended" is supposed to hash user ids? It is very opaque as to what this does. In fact it seems to cover two very different things: the amount of data gathered automatically (which kind of ties in with autoinstrumentation) and the fact that some information may be hashed (which is orthogonal with autoinstrumentation).
And regarding he amount of data gathered automatically I have the feeling that the data gathered should be controllable by the user, e.g here the user may want to configure obtaining the username but not the email.
resource_email = devise_resource.email
resource_username = devise_resource.username
event_information[:email] = resource_email if resource_email
event_information[:username] = resource_username if resource_username
That could give us some configuration that would look like:
c.appsec.user_tracking.collect = :safe
c.appsec.user_tracking.collect = :extended
c.appsec.user_tracking.collect = [ :id ] # equivalent to :save
c.appsec.user_tracking.collect = [ :id, :email, username ] # equivalent to :extended
c.appsec.user_tracking.collect = { email: :email, username: :username } # or something like that
These settings would apply to all instrumented frameworks. They should be overridable per framework:
c.appsec.instrument :devise, **options
... or something like that. Probably out of scope for this PR.
DISABLED_MODE = 'disabled' | ||
EXTENDED_MODE = 'extended' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
safe
does not appear here, so this doesn't feel exhaustive. It feels like it should be an exhaustively listing enum.
The new setting can be configured on the normal Datadog.configure block and with the Env variable DD_APPSEC_AUTOMATED_USER_EVENTS_TRACKING. The valid values are: [:safe, :extended, :disabled]
Allow passing a custom block to all Datadog::Kit::AppSec::Events methods to modify the tags that get emitted
9f28d75
to
76d3abe
Compare
76d3abe
to
8f95f78
Compare
…ule. Move it to Datadog::AppSec::Contrib::Devise::Patcher internal module
c8c619b
to
fd9e0f4
Compare
fd9e0f4
to
131b27e
Compare
module Devise | ||
# Devise integration constants | ||
module Ext | ||
APP = 'devise' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this constant used anywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of the Ext::APP
constants are used at all. We can decide to remove them all, but since is the standard I prefer to remove it on a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we should remove them (and any other unused constant), they're confusing as hell.
General question: should |
Yes. I want to add the integration myself, but for the sake of reducing the amount of code on this PR I wanted to do as a separate PR |
What does this PR do?
The PR adds a new AppSec integration
devise
. The integration is responsible for instrumenting User events:login
, andsingup
.The PR also adds a couple of things:
automated_track_user_events
track_signup
Motivation
Additional Notes
How to test the change?
CI