Link commands are now unencoded by default #2698
Merged
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.
Description
Link commands are typically stored encoded in base64, even when no obfuscation is used during an operation. While the UI and other plugins have been design to accommodate this, it causes some confusion when reading reports or links from the operations API. This PR makes changes to the Link object, specifically its display property, so that whenever a link is retrieved for display purposes, the
command
andplaintext_command
fields are unencoded. The UI, tests, and relevant classes have been modified accordingly.This is sort of a patch for a larger issue, since we really don't need link commands to be stored encoded at all. However, given the amount of refactoring needed within core, plugins, and deployable agents, this should be a stop-gap solution for the time being.
Type of change
How Has This Been Tested?
All operation API endpoints that return links now return
command
andplaintext_command
unencoded, thoughcommand
will be encoded if any obfuscation was used during an operation. The tests have also been updated and pass with these changes.Checklist: