explode enhancement decodeBase64

[muemi03]

Suggestion for explode/implode enhancement.

explode

• adding options.decodeBase64 : decoding Base64 encoded tags.
• adding options.noProperties : properties-bundle.json will not be created.

implode

• encoding Base64 decodeded tags.

decodeBase64 : Especially when comparing policy versions in GitLab it is helpful to understand the differences with decoded Base64 Tags. The explode will substitute "Base64...." tags by "DecodedBase64 tags and replacing the encode value by its decoded version The implode does the opposite, converting the decoded stuff to the encoded again. So, the result of implode looks exactly as the the not yet exploded bundle. Example: graphman.sh explode --input policy.json --output policy --options.level 2 --options.decodeBase64 true

noProperties: In our scenarios, extensively using export and explode to create deployment packages, and finally working with GitLab to understand package contents and finalizing the package content the properties-bundle.json file was always more disturbing, than helpful. Hence, I added the option to omit the properties bundle creation. Example: graphman.sh explode --input policy.json --output policy --options.level 2 --options.decodeBase64 true --options.noProperties true

[muemi03]

Even though I still see an advantage having no base64 encoded content in the XML representation, the direct necessity isn't required anymore. Since graphman-client version v1.3.00 and gateway v1.1.0 YAML as well as JSON is supported as additional code representation formats. These new formats do not contain base64 encoded texts anymore. So comparison of code is much easier now. And this was the original intent of this enhancement. Closing the request

[burbanski]

Thank you, @muemi03 . Note that at this time, YAML and JSON representation of policy are limited Policy as Code preview features. Initial focus was on a handful of assertions that we thought would be most useful for authoring new policies as code. While all assertions will export as XML, YAML or JSON, some other assertions may fail to import as YAML or JSON. We do plan to close this gap and fully support Policy as Code for all assertions in future gateway releases.