-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Security Solutions] Adds a default for indicator match custom query of *:* #81727
Changes from 7 commits
4dc7f3c
4f7756c
9f98bd6
eb32912
a998547
6ac90aa
7bbc2a1
805ce94
402348f
8dee519
0f234ef
499e721
abdaa53
ed94de2
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 |
---|---|---|
|
@@ -71,6 +71,7 @@ const stepDefineDefaultValue: DefineStepRule = { | |
query: { query: '', language: 'kuery' }, | ||
filters: [], | ||
saved_id: undefined, | ||
edited: false, | ||
}, | ||
threatQueryBar: { | ||
query: { query: '*:*', language: 'kuery' }, | ||
|
@@ -131,7 +132,7 @@ const StepDefineRuleComponent: FC<StepDefineRuleProps> = ({ | |
options: { stripEmptyFields: false }, | ||
schema, | ||
}); | ||
const { getFields, getFormData, reset, submit } = form; | ||
const { getFields, getFormData, reset, submit, setFieldValue } = form; | ||
const [ | ||
{ | ||
index: formIndex, | ||
|
@@ -165,7 +166,20 @@ const StepDefineRuleComponent: FC<StepDefineRuleProps> = ({ | |
// reset form when rule type changes | ||
useEffect(() => { | ||
reset({ resetValues: false }); | ||
}, [reset, ruleType]); | ||
if (getFields().queryBar != null) { | ||
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. I think you can use 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. EDIT: Nvm, I see reset was called beforehand. 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. I would isolate this logic to a separate |
||
const queryBar = getFields().queryBar.value as DefineStepRule['queryBar']; | ||
if (queryBar.edited !== true && !isUpdateView) { | ||
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. FYI this Perhaps we could use 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. In talking with @FrankHassanabad I wanted to add this to our team discussion. It's becoming increasingly more difficult to make any changes without either 1) breaking another rule type's logic or 2) adding extra validations throughout. It's feeling like a bit of wack-a-mole. I almost want to just silo off each rule type. One example I ran into with preview was that each rule held the state of other rule types (if let's say I visited Threshold and set some state and then switched to custom query) and had to add logic to ensure that it was picking up and ignoring the right parts. 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. @yctercero Would the schemas here help to silo off the rule types in the frontend code? I created them with a similar goal in mind for the backend of making it clear which fields are valid for each rule type, as well as defining which fields are shared across all rule types. They're usable in the frontend as well but I'm not sure if they fully implement the siloing you have in mind.
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. @marshallmain yea, I think they would. It might add more touchpoints in the front, but that may be worth the security of not having to worry that an edit to one rule will break another. 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. @ryland, The // reset form when rule type changes
useEffect(() => {
reset({ resetValues: false });
if (getFields().queryBar != null) {
const queryBar = getFields().queryBar.value as DefineStepRule['queryBar'];
if (
isThreatMatchRule(ruleType) &&
(getFields().queryBar.isPristine || queryBar.query.query === '')
) {
setFieldValue('queryBar', {
...stepDefineDefaultValue.queryBar,
query: { ...stepDefineDefaultValue.queryBar.query, query: '*:*' },
});
} else if (getFields().queryBar.isPristine || queryBar.query.query === '*:*') {
setFieldValue('queryBar', stepDefineDefaultValue.queryBar);
} else {
setFieldValue('queryBar', queryBar);
}
}
}, [reset, ruleType, setFieldValue, getFields, isUpdateView]); It still won't work all the way because
else {
setFieldValue('queryBar', queryBar);
} The forms code if it sees the queryBar value is the same as before it will not trigger pristine back to false. So pristine becomes not useful here. However, to remove the edit flag I added at a trade off of the forms having funny quirks if a user decides to use // reset form when rule type changes
useEffect(() => {
reset({ resetValues: false });
const queryBar = getFields().queryBar.value as DefineStepRule['queryBar'];
if (getFields().queryBar != null) {
if (isThreatMatchRule(ruleType) && queryBar.query.query === '') {
setFieldValue('queryBar', {
...stepDefineDefaultValue.queryBar,
query: { ...stepDefineDefaultValue.queryBar.query, query: '*:*' },
});
} else if (queryBar.query.query === '*:*') {
setFieldValue('queryBar', stepDefineDefaultValue.queryBar);
}
}
}, [reset, ruleType, setFieldValue, getFields, isUpdateView]); That would just hardcode the two conditions of either detecting an empty string or detecting a If that is deemed the "the lesser of evils" with what we already have in the forms code I can commit the code above. 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. Actually after messing around with it @rylnd I was able to accomplish everything the edited flag could using a combination of the // reset form when rule type changes
useEffect(() => {
reset({ resetValues: false });
const { queryBar } = getFields();
if (queryBar != null && !isUpdateView) {
if (isThreatMatchRule(ruleType) && queryBar.isPristine) {
queryBar.reset({
defaultValue: {
...stepDefineDefaultValue.queryBar,
query: { ...stepDefineDefaultValue.queryBar.query, query: '*:*' },
},
});
} else if (queryBar.isPristine) {
queryBar.reset({
defaultValue: {
...stepDefineDefaultValue.queryBar,
query: { ...stepDefineDefaultValue.queryBar.query, query: '' },
},
});
} else {
// This ensures the isPristine is still set to false after a user has modified it
queryBar.setValue((prev: DefineStepRule['queryBar']) => ({ ...prev }));
}
}
}, [reset, ruleType, getFields, isUpdateView]); |
||
if (isThreatMatchRule(ruleType)) { | ||
setFieldValue('queryBar', { | ||
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.
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. Thanks, see comments above, I can use this in combination with reset and I think we are going to get what we want out of this feature in a more straight forward way. |
||
...stepDefineDefaultValue.queryBar, | ||
query: { ...stepDefineDefaultValue.queryBar.query, query: '*:*' }, | ||
}); | ||
} else { | ||
setFieldValue('queryBar', stepDefineDefaultValue.queryBar); | ||
} | ||
} | ||
} | ||
}, [reset, ruleType, setFieldValue, getFields, isUpdateView]); | ||
|
||
useEffect(() => { | ||
setIndexModified(!isEqual(index, indicesConfig)); | ||
|
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.
You shouldn't need
setFieldValue
here, you can instead use[field].setValue
as inhandleResetIndices
below.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.
Thanks, I think this is a dead variable at this point and I don't use it below anymore so this will be removed.