You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #41196 we sought to limit the amount of memory held when reading in a realm file. We also discussed that the replacement strategy is overly general.
The previous/current logic happens before any structural parsing - it doesn't matter what the String content is - xml, json, yaml, etc. it just looks for ${...}. If you try to inline json into a json file, that will work - as long as after the replacement occurs things remain structurally valid.
This is likely an undocumented / unintended consequence of the original implementation and it does make dealing with simple replacements more complicated or unintuitive. Following the documentation example: "realm": "${MY_REALM_NAME}" you have to know that MY_REALM_NAME must be equal to a JSON string without the surrounding double qoutes (this isn't explicitly documented). This makes the appearence of \ or " in the replacement something that probably requires trial and error or examining the source code.
However it is entirely possible that someone has figured out this general mechanism and is doing something clever like have composable realm imports - where common elements could be shared via environment variables. Supporting such a scheme post parsing is simply not possible because the original file will not be structurally valid, so if we allow that style of replacement we'll have to keep around this existing code path in some form.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
With #41196 we sought to limit the amount of memory held when reading in a realm file. We also discussed that the replacement strategy is overly general.
The previous/current logic happens before any structural parsing - it doesn't matter what the String content is - xml, json, yaml, etc. it just looks for ${...}. If you try to inline json into a json file, that will work - as long as after the replacement occurs things remain structurally valid.
This is likely an undocumented / unintended consequence of the original implementation and it does make dealing with simple replacements more complicated or unintuitive. Following the documentation example:
"realm": "${MY_REALM_NAME}"you have to know that MY_REALM_NAME must be equal to a JSON string without the surrounding double qoutes (this isn't explicitly documented). This makes the appearence of \ or " in the replacement something that probably requires trial and error or examining the source code.We should consider whether we want to continue to support such a general replacement mechanism or if we should utilize one that happens after the initial parsing - see for example openshift templates https://docs.redhat.com/en/documentation/openshift_container_platform/4.9/html/images/using-templates
However it is entirely possible that someone has figured out this general mechanism and is doing something clever like have composable realm imports - where common elements could be shared via environment variables. Supporting such a scheme post parsing is simply not possible because the original file will not be structurally valid, so if we allow that style of replacement we'll have to keep around this existing code path in some form.
cc @keycloak/cloud-native
All reactions