-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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 Solution][Exceptions] - Fixes exceptions builder UI where invalid values can cause overwrites of other values #90634
Conversation
if (validatedEntry != null || validatedNestedEntry != null) { | ||
return true; | ||
} | ||
if (singleEntry.type === 'nested') { |
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.
A bit more verbose but I think easier to understand.
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
@@ -0,0 +1,23 @@ | |||
{ |
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.
For the modal cypress tests, it was unnecessary to load a large file such as auditbeat, needed a small simple nested a non-nested field to test with is all.
…ting lists plugin useApi hook (#92348) Doing a quick refactor to help with #90634 . While working on #90634 found that I would introduce a circular dependency if I didn't refactor the hook used by the exception builder component to make use of the existing useApi hook in the lists plugin. #90634 adds temporary ids to item entries to mitigate some React key requirements and the logic to remove/add these id's isn't at the boundary but in the hooks (so as not to pollute the data for everyone wanting to use the api. An upside is that it removed some of the looping and seemed to speed things up a bit. I briefly considered adding the bulk SO endpoints for exception items, but they are still experimental.
…ting lists plugin useApi hook (elastic#92348) Doing a quick refactor to help with elastic#90634 . While working on elastic#90634 found that I would introduce a circular dependency if I didn't refactor the hook used by the exception builder component to make use of the existing useApi hook in the lists plugin. elastic#90634 adds temporary ids to item entries to mitigate some React key requirements and the logic to remove/add these id's isn't at the boundary but in the hooks (so as not to pollute the data for everyone wanting to use the api. An upside is that it removed some of the looping and seemed to speed things up a bit. I briefly considered adding the bulk SO endpoints for exception items, but they are still experimental.
…ting lists plugin useApi hook (elastic#92348) Doing a quick refactor to help with elastic#90634 . While working on elastic#90634 found that I would introduce a circular dependency if I didn't refactor the hook used by the exception builder component to make use of the existing useApi hook in the lists plugin. elastic#90634 adds temporary ids to item entries to mitigate some React key requirements and the logic to remove/add these id's isn't at the boundary but in the hooks (so as not to pollute the data for everyone wanting to use the api. An upside is that it removed some of the looping and seemed to speed things up a bit. I briefly considered adding the bulk SO endpoints for exception items, but they are still experimental.
…ting lists plugin useApi hook (#92348) (#92534) Doing a quick refactor to help with #90634 . While working on #90634 found that I would introduce a circular dependency if I didn't refactor the hook used by the exception builder component to make use of the existing useApi hook in the lists plugin. #90634 adds temporary ids to item entries to mitigate some React key requirements and the logic to remove/add these id's isn't at the boundary but in the hooks (so as not to pollute the data for everyone wanting to use the api. An upside is that it removed some of the looping and seemed to speed things up a bit. I briefly considered adding the bulk SO endpoints for exception items, but they are still experimental.
…ting lists plugin useApi hook (#92348) (#92535) Doing a quick refactor to help with #90634 . While working on #90634 found that I would introduce a circular dependency if I didn't refactor the hook used by the exception builder component to make use of the existing useApi hook in the lists plugin. #90634 adds temporary ids to item entries to mitigate some React key requirements and the logic to remove/add these id's isn't at the boundary but in the hooks (so as not to pollute the data for everyone wanting to use the api. An upside is that it removed some of the looping and seemed to speed things up a bit. I briefly considered adding the bulk SO endpoints for exception items, but they are still experimental.
operator: 'included', | ||
type: 'match', | ||
value: 'some value', | ||
} as EntryMatch & { id: 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.
Nit, but you could create an EntryId
to reuse the { id: string }
pattern that occurs frequently. May not be worth it.
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.
fwiw, when I fixed mine id's up, I got the same feedback where the suggestion was I just do a cast and very carefully do the cast in a few areas from @rylnd as the lesser of the evils and only add the extra id in only a few typings and only where I needed it. That felt more right to get past this issue.
I did this type of thing very carefully only where I needed the id:
const maybeId: typeof item & { id?: string } = item;
Everywhere else I left the typings alone. I think @madirey 's suggestions are good as well, it's a bit of a balancing act and your choice in these areas.
Later if we push the id down to the data layer or in the REST routes we can make the id's part of the schema and be ok as well. This all looks good to me here as is though too.
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, yea I could definitely see that it could maybe be cleaned up. I tried to add comments where there were casts to give an explanation of it.
There's a number of refactors that I'd like to do to follow up. If it's ok, I think it could be addressed then?
|
||
test('it invokes "addExceptionListItem" when payload has "id"', async () => { | ||
const updateExceptionItem = jest.spyOn(api, 'updateExceptionListItem'); | ||
const createExceptionItem = jest.spyOn(api, 'addExceptionListItem'); |
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.
The naming here is a little confusing because it's called addExceptionItem
in the test above this one, yet it's mocking the same thing.
} | ||
} | ||
} | ||
} |
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.
fwiw, something I wished I had done before was add this to some of my tests and mappings:
Which is a "refresh_interval": "5s"
it reduces flake and speeds things up if you're pushing data from es archiver into it. Optional as I forget to add it. Without it, I think the default of tests are 1 minute. They might have changed the default for tests that I don't know about, but I don't know the answer to that either.
@@ -282,6 +285,7 @@ export const getUpdatedEntriesOnDelete = ( | |||
const { field } = itemOfInterest; | |||
const updatedItemOfInterest: EntryNested | EmptyNestedEntry = { | |||
field, | |||
id: itemOfInterest.id ?? `${entryIndex}`, |
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.
Will this exceptional case ever happen?
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.
id
is mapped to string | undefined
as I can't truly guarantee that the id will be there given it's not actually part of the schema so I hesitated to not use id?
. The entries that are typed as empty entries have id
set as just string
(as opposed to string | undefined
) because we're creating those client side and can guarantee we'll stick an id
in there.
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @yctercero |
…nvalid values can cause overwrites of other values (elastic#90634) ### Summary This PR is a follow-up to elastic#89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder.
…nvalid values can cause overwrites of other values (elastic#90634) ### Summary This PR is a follow-up to elastic#89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder.
…nvalid values can cause overwrites of other values (#90634) (#92749) ### Summary This PR is a follow-up to #89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder. Co-authored-by: Kibana Machine <[email protected]>
* master: (38 commits) Fixes Cypress flake by adding pipe, click, and should (elastic#92762) [Discover] Fix filtering selected sidebar fields (elastic#91828) [ML] Fixes positions of calendar arrow buttons in start datafeed modal (elastic#92625) [dev/build_ts_refs] check that commit in outDirs matches mergeBase (elastic#92513) add dep on `@kbn/config` so it is built first [Expressions] [Lens] Add id and copyMetaFrom arg to mapColumn fn + add configurable onError argument to math fn (elastic#90481) [Lens] Fix Workspace hidden when using Safari (elastic#92616) [Lens] Fixes vertical alignment validation messages (elastic#91878) forbid x-elastic-product-origin header in elasticsearch configuration (elastic#92359) [Security Solution][Detections] Set default indicator path to reduce friction with new filebeat modules (elastic#92081) [ILM][Accessibility] Added A11y test for ILM new policy form. (elastic#92570) [Security Solution][Exceptions] - Fixes exceptions builder UI where invalid values can cause overwrites of other values (elastic#90634) Automatically generated Api documentation (elastic#86232) Increase index pattern select limit to 1000 (elastic#92093) [core.logging] Add RewriteAppender for filtering LogMeta. (elastic#91492) [Security Solution][Detection Rules] Update prebuilt rule threats to match schema (elastic#92281) [Security Solutions][Detection Engine] Fixes bug with not being able to duplicate indicator matches (elastic#92565) [Dashboard] Export appropriate references from byValue panels (elastic#91567) [Upgrade Assistant] Align code between branches (elastic#91862) [Security Solution][Case] Fix alerts push (elastic#91638) ...
…nvalid values can cause overwrites of other values (#90634) (#92750) ### Summary This PR is a follow-up to #89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder. Co-authored-by: Kibana Machine <[email protected]>
Summary
This PR is a follow-up to #89066 - which fixed the same issue occurring with indicator match lists UI. The lack of stable ids for exception item entries resulted in some funky business by where invalid values could overwrite other values when deleting entries in the builder.
Some interesting discussions came of it of whether it's tech debt from not adding such ids to begin with into the exceptions data structure. On the other side of the argument is that the ids have only really been needed for React specific purposes. The fix is to add a
uuid.v4()
to entry items at the API inbound boundary and a util to strip suchid
out on the outbound boundaries.At first, thought of adding the
id
as close to the boundary as possible, so then anyone using the exceptions API on the UI would receive this added functionality. After a bit of discussion with team, found it made more sense to keep it to the hooks and leave the api calls themselves pure.Bug
Notice I select start with
a, c, d, e
--> select to deleted
--> remain witha, c, d
bug_1.mov
Notice I select start with
a, c
--> select to deletea
--> all clear outbug_2.mov
Fix
Notice I select start with
[a,b], [c,d,e]
--> select to deleted
--> left with[a,b], [c, e]
Notice I select start with
[b], [c,e]
--> select to deletec
--> left with[b], [e]
--> select to deleteb
--> left with[e]
Checklist