Keyword replace mappings (# / @) in configs don't support concatenating arrays

[gaui]

Description

Provide a clear and concise description of the issue, including what you expected to happen.

Placeholders ##x## or @@x@@ don't support concatenating arrays. Sometimes you would like to concatenate arrays, e.g. allowed callback URLs, logout URLs or web origins. For example having base/global allowed URLs defined, and then adding to them for all clients/applications.

config.json

{
	"AUTH0_KEYWORD_REPLACE_MAPPINGS": {
		  "GLOBAL_WEB_ORIGINS": [
			"http://local.me:8080",
			"http://localhost",
			"http://localhost:3000"
		  ]
	}
}

def/clients/A.json

Either ##:

{
    "web_origins": [
        "##GLOBAL_WEB_ORIGINS##",
        "http://a.foo.com",
        "https://a.foo.com"
    ]
}

or @@

{
    "web_origins": [
        @@GLOBAL_WEB_ORIGINS@@,
        "http://a.foo.com",
        "https://a.foo.com"
    ]
}

Expected result:

{
    "web_origins": [
        "http://local.me:8080",
        "http://localhost",
        "http://localhost:3000",
        "http://a.foo.com",
        "https://a.foo.com"
    ]
}

Actual result:

I get an error for @@ but for ## I get the following:

{
    "web_origins": [
        "http://local.me:8080,http://localhost,http://localhost:3000",
        "http://a.foo.com",
        "https://a.foo.com"
    ]
}

Environment

Please provide the following:

• Version of this library used: 3.6.3
• Other relevant versions (language, server software, OS, browser): Node 8.15.1, Linux Mint, Ubuntu 18.04
• Other modules/plugins/libraries that might be involved: N/A

[aaron-fuleki]

Same. I've tried various incantations of escaping/nesting, and none have worked. I can fix things manually in the web UI, but the CI pipeline will pave over that on the next deploy, so that's not a valid workaround.

[jermeo]

Hello, same problem for me.
Currently, we use several reserved spaces for temporary solution but it's not flexible, like this:

{
    "web_origins": [
        ##GLOBAL_WEB_ORIGIN_1##,
        ##GLOBAL_WEB_ORIGIN_2##,
        "http://a.foo.com",
        "https://a.foo.com"
    ]
}

[rodschuler]

I was having the same problem but was able to get it to work by doing the following.

In the yaml file I have

web_origins: [##APP_WEB_ORIGINS##]

and then in the config file you set it up similar to the following

"AUTH0_KEYWORD_REPLACE_MAPPINGS": { "APP_WEB_ORIGINS": "'https://a.foo.com','https://b.foo.com','https://c.foo.com'", }

basically using single quotes inside the variable used to replace the value.

[willvedd]

@rodschuler Thanks for posting that workaround, seems like a tenable solution. Though it highlights areas of potential improvement for the variable replacement functionality in general.

[zchryst]

above didn't work for me - but for those facing the same issue this did:

"AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "SOME_URLS": [
      "\"https://localhost/mycallback\"",
      "\"https://localhost:3000\"",
      "\"https://localhost:3000/\"",
      "\"http://localhost:3000/mycallback\"",
      "\"http://localhost:3000/something-silly\""
    ]
  }

Ain't perty - but does the trick

[willvedd]

This type of concatenation does not have first-class support through either of the existing keyword replacement syntaxes. However, it is possible to achieve the desired effect by escaping double quotes in a long string and injecting with the ## syntax.

Example:

config.json

{
  "AUTH0_KEYWORD_REPLACEMENT": {
    "GLOBAL_WEB_ORIGINS": "\"http://local.me:8080\", \"http://localhost\", \"http://localhost:3000\""
  }
}

tenant.yaml

clients:
  - name: Test App
    web_origins: [ "http://production-app.com", "https://production-app.com", ##GLOBAL_WEB_ORIGINS## ]

Despite the use case being quite reasonable, it's unlikely that we would prioritize development to support more formally. Especially given that the provided workaround is straightforward enough. I've opened #619 to add reference of this in the docs as well as adding a couple test cases to ensure that the workaround continues to function over time. Thus, I'm considering this ticket resolved. Appreciate everyone's patience and input on this one!