Permit passing config object via env vars

[alukach]

What I'm changing

If a config value is an object, the tooling to convert it from an environment var to JS will keep it as a string (see #460).

This PR will instead retain its state as a JSON object.

This will allow the following configurations to be correctly set via environment variables:

▶ cat config.schema.json | jq '.properties | to_entries | map(select(.value.type[0] == "object")) | map(.key)'
[
  "requestHeaders",
  "requestQueryParameters",
  "authConfig"
]

How I did it

The inability to pass in objects via ENV vars was caused by the fact that when we parse the SB_* environment values based on their type as specified in the config.schema.json; however, we don't specifically handle the object type so it is run through the catch-all safe_echo code:

stac-browser/config.schema.json

Lines 225 to 236 in 108947e

	"authConfig": {
	"type": [
	"object"
	],
	"allOf": [
	{
	"$ref": "https://stac-extensions.github.io/authentication/v1.1.0/schema.json"
	}
	],
	"noCLI": true,
	"noEnv": true
	}

stac-browser/docker/docker-entrypoint.sh

Lines 58 to 92 in 108947e

	env -0 | cut -f1 -d= | tr '\0' '\n' | grep "^SB_" | {
	echo "window.STAC_BROWSER_CONFIG = {"
	while IFS='=' read -r name; do
	# Strip the prefix
	argname="${name#SB_}"
	# Read the variable's value
	value="$(eval "echo \"\$$name\"")"
	# Get the argument type from the schema
	argtype="$(echo "$config_schema" | jq -r ".properties.$argname.type[0]")"
	arraytype="$(echo "$config_schema" | jq -r ".properties.$argname.items.type[0]")"
	# Encode key/value
	echo -n " $argname: "
	case "$argtype" in
	string)
	safe_echo "$value"
	;;
	boolean)
	bool "$value"
	;;
	integer | number)
	object "$value"
	;;
	array)
	array "$value" "$arraytype"
	;;
	*)
	safe_echo "$value"
	;;
	esac
	echo ","
	done
	echo "}"
	} > /usr/share/nginx/html/config.js

This keeps it as a string:

stac-browser/docker/docker-entrypoint.sh

Lines 1 to 2 in 108947e

	# echo a string, handling different types
	safe_echo() {

However, if we permit configurations of type "object" to encoded directly into the JSON via the object() function in the bash script, we can use them as standard configuration.

How you can test this

Before

On the main branch:

1. Build docker image: docker build -t stac-browser
2. Run docker image with auth config set as environment variable: docker run -it -e SB_authConfig='{"foo": "bar"}' --name stac-browser stac-browser
3. In another terminal, review the generated config: docker exec stac-browser cat /usr/share/nginx/html/config.js

You should see an object where the authConfig property is a string rather than an object:

window.STAC_BROWSER_CONFIG = {
  authConfig: '{"foo": "bar"}',
}

After

Following the above steps on this branch, you should see now see an object where the authConfig property is an object:

window.STAC_BROWSER_CONFIG = {
  authConfig: {"foo": "bar"},
}

---

closes #460

[m-mohr]

Thank you for the suggestion.
Indeed, it is not supported to pass objects via ENV or CLI and it is reflected as such in the docs and config.schema.js.
If this works reliably, this should be reflected in the docs and in the config.schema.js.

[alukach]

@m-mohr Ah, I had missed those details. Thanks for pointing out that this is documented and intended behavior. In 408ed94 and 88212c8 I've removed such documentation in hopes that we can indeed adjust this beavior.

[alukach]

(Seeing that this PR is not a trivial one-liner as I had initially hoped, I've updated the description in hopes of adding more clarity to what is being changed and why)

[m-mohr]

Hi @alukach

I checked this again, but I'm not sure how this allows supporting objects. I only see changes in the Docker environment, but not generally in the non-Docker part of STAC Browser. As such I'm not sure how this is meant to work?! Can you provide an example, please?

[alukach]

@m-mohr you're correct, non-dockerized environments were not addressed. They are now addressed via b738e4e. Do you require a more substantial demonstration of its functionality?

[m-mohr]

Thanks. This looks reasonable, but I don't see any effect.

For example, npm run build -- --requestHeaders="{"x-example": "abc"}" doesn't seem to have any effect. How did you confirm that the changes work? What example did you test it with?

Edit: On the other hand I can't currently provide anything via CLI parameter, it seems. Hmm... => #529

[alukach]

@m-mohr For testing, I've been using npm start:

npm start -- --open --catalogUrl "https://earth-search.aws.element84.com/v1/" --authConfig '{ "type": "openIdConnect", "openIdConnectUrl": "https://cognito-idp.us-east-1.amazonaws.com/abcd123/.well-known/openid-configuration", "oidcOptions": { "client_id": "stac-browser" } }'

Note the rendered auth button:

For example, npm run build -- --requestHeaders="{"x-example": "abc"}" doesn't seem to have any effect.

Not sure if this is the exact reason for your issues, but you should wrap the JSON in single quotes rather than double quotes.

[alukach]

@m-mohr I've removed bd68d93 from this PR as I have been unable to replicate this issue.

With the following command:

npm start -- --open --catalogUrl "https://earth-search.aws.element84.com/v1/" --requestHeaders='{"X-Amzn-Trace-Id": "example"}'  

I can see that the trace ID is correctly set on all outgoing requests (I use that header to conform with the access-control-allow-headers response returned by the server on OPTIONS requests).

[m-mohr]

Something must be off on my machine, I can't provide anything via CLI right now. Might be a Windows thing or something is broken in a specific npm/node/vue-cli version. Need to investigate. Can't really test this PR right now. But good to know that this is working for you.

bd68d93 came from the master branch.

[m-mohr]

Okay, I can confirm that this works. It is an npm bug on Windows that prevented me from testing this. I didn't test the Docker implementation as I'm not using Docker. Thank you for the contribution @alukach!