-
Notifications
You must be signed in to change notification settings - Fork 515
o365: Fix the handling of duplicated field QueryTime #11499
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
o365: Fix the handling of duplicated field QueryTime #11499
Conversation
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
🚀 Benchmarks reportTo see the full report comment with |
|
💚 Build Succeeded
|
efd6
left a comment
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.
They are not technically wrong; RFC 8259 only says that "The names within an object SHOULD be unique." (section 4). Not nice though. (RFC 7493 does prohibit this.)
|
Package o365 - 2.6.5 containing this change is available at https://epr.elastic.co/search?package=o365 |
Some events from O365 introduce a duplicated QueryTime field. To fix the error it was added a gsub processor that attempts to find the undesired QueryTime field and removed from the whole Data object. In addition, to prevent other similar issues, added a on_failure case when decoding the Data field which generally contains unknown fields.
Some events from O365 introduce a duplicated QueryTime field. To fix the error it was added a gsub processor that attempts to find the undesired QueryTime field and removed from the whole Data object. In addition, to prevent other similar issues, added a on_failure case when decoding the Data field which generally contains unknown fields.




Proposed commit message
For some unknown reason we couldn't find out, some events from O365 introduces a malformed JSON object by adding a duplicated
QueryTimefield. The pattern this issue follows is:RecordType == 64QueryTimefield doesn't follow ISO8601 format.So the pipeline fails with:
To fix the error it was added a
gsubprocessor that attempts to find the undesiredQueryTimefield and removed from the wholeDataobject. In addition, to prevent other similar issues, added aon_failurecase when decoding theDatafield which generally contains unknown fields.Checklist
changelog.ymlfile.Related issues