-
Notifications
You must be signed in to change notification settings - Fork 246
DRIVERS-1653 Add observeSensitiveCommands property to the client entity type #1015
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
Changes from all commits
40033ed
16b489c
e940f26
17acc9c
f33a6d5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3,7 +3,7 @@ Unified Test Format | |
| =================== | ||
|
|
||
| :Spec Title: Unified Test Format | ||
| :Spec Version: 1.4.1 | ||
| :Spec Version: 1.5.0 | ||
| :Author: Jeremy Mikola | ||
| :Advisors: Prashant Mital, Isabel Atkinson, Thomas Reggi | ||
| :Status: Accepted | ||
|
|
@@ -414,6 +414,8 @@ The structure of this object is as follows: | |
| treat the comparison as not equal and skip the test. This includes errors that | ||
| occur when fetching a single parameter using ``getParameter``. | ||
|
|
||
| .. _runOnRequirement_auth: | ||
|
|
||
| - ``auth``: Optional boolean. If true, the tests MUST only run if authentication | ||
| is enabled. If false, tests MUST only run if authentication is not enabled. | ||
| If this field is omitted, there is no authentication requirement. | ||
|
|
@@ -543,11 +545,21 @@ The structure of this object is as follows: | |
| ``configureFailPoint`` and any commands containing sensitive information | ||
| (per the | ||
| `Command Monitoring <../command-monitoring/command-monitoring.rst#security>`__ | ||
| spec). | ||
| spec) unless ``observeSensitiveCommands`` is true. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For context, the original text of "the command(s) will be ignored in addition to Furthermore, I was oblivious to the issue described in CDRIVER-3797 where an event might be emitted for the createUser helper, since PHP doesn't use those helpers at all nor does it provide its own. |
||
|
|
||
| Test files SHOULD NOT use this option unless one or more command monitoring | ||
| events are specified in `observeEvents <entity_client_observeEvents_>`_. | ||
|
|
||
| - ``observeSensitiveCommands``: Optional boolean. If true, events associated | ||
| with sensitive commands (per the | ||
| `Command Monitoring <../command-monitoring/command-monitoring.rst#security>`__ | ||
| spec) will be observed for this client. If false or not specified, events for | ||
| commands containing sensitive information MUST be ignored. | ||
| Authentication SHOULD be disabled when this property is true, i.e. | ||
| `auth <runOnRequirement_auth_>`_ should be false for each ``runOnRequirement``. | ||
| Test runners MUST fail if ``observeSensitiveCommands`` is true and | ||
| authentication is enabled. See `rationale_observeSensitiveCommands`_. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. tl;dr: I suggest removing "Test runners MUST fail if I don't think this needs to be a requirement since it's adding a bit of complexity to the implementation just to protect users from occasional test failures (e.g. the example where If I understand correctly, this doesn't actually care about This is asking a test runner to inspect the environment in an entirely different place than when runOnRequirements might typically be resolved, so my preference would be to just get rid of this and if someone writes a bad test that unexpectedly fails we either catch that during review or after the fact when it inevitably fails on an auth environment. I was originally going to suggest adding a "valid-fail" for this but I realize we probably can't do that since there's no guarantee the test would run against an auth-enabled cluster in the first place. Even if such a "valid-fail" test used |
||
|
|
||
| .. _entity_client_storeEventsAsEntities: | ||
|
|
||
| - ``storeEventsAsEntities``: Optional array of one or more | ||
|
|
@@ -3101,6 +3113,22 @@ The specification does prefer "MUST" in other contexts, such as discussing parts | |
| of the test file format that *are* enforceable by the JSON schema or the test | ||
| runner implementation. | ||
|
|
||
| .. _rationale_observeSensitiveCommands: | ||
|
|
||
| Why can't ``observeSensitiveCommands`` be true when authentication is enabled? | ||
| ------------------------------------------------------------------------------ | ||
|
|
||
| When running against authentication-enabled clusters, the events observed by a | ||
| client will always begin with auth-related commands (e.g. ``authenticate``, | ||
| ``saslStart``, ``saslContinue``) because the MongoClient will need to | ||
| authenticate a connection before issuing the first command in the test | ||
| specification. Since the exact form of the authentication command event will | ||
| depend on whether authentication is enabled, as well as, the auth mechanism in | ||
| use, it is not possible to anticipate the command monitoring output and perform | ||
| the appropriate assertions. Consequently, we have restricted use of this property | ||
| to situations where authentication is disabled on the server. This allows | ||
| tests to explicitly test sensitive commands via the ``runCommand`` helper. | ||
|
|
||
|
|
||
| Breaking Changes | ||
| ================ | ||
|
|
@@ -3212,6 +3240,9 @@ spec changes developed in parallel or during the same release cycle. | |
| Change Log | ||
| ========== | ||
|
|
||
| :2021-06-09: Added an ``observeSensitiveCommands`` property to the ``client`` | ||
| entity type. | ||
|
|
||
| :2021-05-17: Ensure old JSON schema files remain in place | ||
|
|
||
| :2021-04-19: Introduce ``serverless`` `runOnRequirement`_. | ||
|
|
||
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.
In regard to @kmahar and @benjirewis's concerns about this version bump, I think it's quite possible that drivers could add support for this new option (1.5) without implementing everything in previous schema versions. This requires some manual tracking on their end, but it's the same approach I took when prototyping Atlas testing (1.2) before versioned API was implemented (1.1). I bumped our internal test runner's supported schema version to 1.2 and left a comment that features in 1.1 were not supported.
I concur that it's a crappy work-around, but I don't see another way given our versioning. @alcaeus has floated the idea of instead categorizing test runner features with tags and having tests enumerate which features they depend on, but I think that has the possibility of getting quite messy as well (especially if the same "named" feature were to have multiple variations/versions over time).