[MAPPS-4798] normalize configuration input account for case-… #151
+44
−10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Jira Link: https://sentinelone.atlassian.net/browse/MAPPS-4798
🥅 Goal
Enable case-insensitive handling of input account configuration in the SDL Dataset Add-on for Splunk to eliminate the need for duplicate configuration objects.
Issue:
Splunk indexing is case-insensitive, but the SDL Dataset Add-on treated input account configuration values as case-sensitive. Due to this mismatch, customers were required to create multiple configuration objects with different casing to ensure proper token resolution, which is error-prone and not scalable.
🛠️ Solution
Updated the add-on logic to standardize and normalize input account configuration handling. The input account can now be searched and matched in a case-insensitive manner while still enforcing exact word matching, ensuring consistent behavior across different case formats without requiring duplicate configurations.
🏫 Testing
Validated the fix on a local Splunk instance by testing multiple input account configurations with varying case formats. Confirmed that all configurations correctly resolve to the intended token and that data ingestion works as expected without requiring duplicate configuration objects.