Token in Service Provider Configuration usage

This is an old thread but I wanted to check in on what, if anything, happened with this feature request. For a multisite (dev-test-live) it would be helpful to have a site token in the EntityID. E.g. [site:base-url]/saml/metadata Tokens in Name ID and/or Idp are not relevant to my needs.
Any comment around this is appreciated. Thanks.

@roderik Drupal core uses this for handling tokens in the 'user registration' emails. The language is stored in configuration and can contain tokens for replacing text, so there is precedence/existing examples of this working even in core.

I am not sure how common using configuration split is, but all of this is easily achievable using configuration split and splitting the saml_auth.authentication file into each environment separately with it's own values.

@jfurnas thank you for the help.

The answer to the original question is: nothing happened with this feature request. Because there was no response in 5 years and noone else mentioned it until now.

In the meantime I still don't claim to be an expert on configuration best practices and can't tell you which exact helpers (config_* modules) are the most perfect for which circumstances... but I've seen a few deployment mechanisms for different environments in a few companies, and all of them need to do some kind of rewriting of configuration values. So adding the rewriting of this specific configuration value on top of the same mechanism, should not be a lot of overhead.

I can indeed see a case specifically for using [site:base-url] in the SP Entity ID, because it's so common to use an URL in the entity ID, and because we know the base url value really comes from the system (it's not dependent on any user-input/modifiable value)**. For the rest, I'm still wary of doing any token replacement. So I'd add a patch/MR that

• does a specific replacement of '[site:base-url]' in the SP entity ID value
• mentions this in the help/description text for the SP Entity ID input.

I don't want to apply the current patch, because I feel that it's good to be 'overly paranoid' for this module; to fear any kind of overwriting in configuration values that could somehow come from 'user input'. Allowing any token replacement feels too generic (for no proven purpose). And I still can't think of a proper use case other than the base URL.

(Also: Yes, Core replaces tokens in a (email) text which is saved as a configuration value. That's true. But I don't see an email text on the same level as other configuration values that govern how a site works.)

** Well, technically... until #2404601: Figure out how to best deal with RequestContext::setCompleteBaseUrl → is fixed, some other code could modify the value by calling setBaseUrl(). But code execution is not user input; if someone can manipulate code to do this, then your sites has bigger issues already.

Thanks @roderik. I agree with you and can't think of another use case other than [site:base-url] from the site environment.