Centralised environment config

#1

Hi all,

We’ve got a complex little bundle of assets that I’ve just migrated from our UAT to Prod environment using the Export / Import Assets From XML Tool.

Unfortunately there are numerous attributes to update around the place relating to the change in environment, eg:

  • 3rd party URLs in Call REST Resource submission actions
  • API Keys in authorisation headers in REST Resource assets
  • Certificate strings in SSJS content containers
  • etc

Is there any sort of best practice approach to centralising all this config this in Squiz? Ideally in a way where I could deploy the same bundle of assets to both environments and it would use the appropriate environment config.

My initial thought is to use a standard page with some SSJS to serve up a config value:
%globals_asset_contents_raw:1234^with_get:param=blah^run_ssjs%

… but will such a keyword replacement even work in fields like authorisation header? Or in other SSJS code blocks? And will it be horrible for performance?

Hoping others have already crossed this bridge and have some sage advice for me :slight_smile:

Cheers
Alex

(Bart Banda) #2

Performance shouldn’t be impacted when using global keywords for this, which is what I would suggest you do to manage these global variables. Even if it’s just a standard page somewhere in your system with a metadata schema that holds all the fields and then you just go %globals_asset_metadata_variable:1234%

#3

Thanks @Bart, much appreciated.

I haven’t worked much with metadata schemas before, am I correct in understanding that as long as Show On Frontend = No that these values are relatively secure?

I’m assuming the only way these would be discoverable to a bad actor is if they were to find a way to inject a globals keyword somewhere, and knew the asset ID and variable name. Which admittedly seems unlikely, but still makes me uncomfortable so I guess I’ll stick with hardcoding the sensitive stuff like API keys.

It would be great if Squiz had something like a ‘server secret’ asset type that allows a value to be known to the backend but encoded/flagged in a way that it’s prevented from ever being printed to the frontend.

Cheers
Alex

(Bart Banda) #4

Yeah they’re not really “secure” in the true sense, because if someone knows the asset ID and you have a template that prints all metadata data in a keyword such as %asset_data% or %asset_data_metadata% then it could be exposed, but yeah, only if implemented as such.

This has come up in the past to be able to have server-side environmental variables like this, so it’s definitely good feedback that I’ll take back to the team for future consideration.