Is your feature request related to a problem? Please describe.
This is both a bug and a feature request.
The current way to expand env variables in the Dex config is error-prone, since it happens before the YAML parsing.
Therefore, weird hacks are needed e.g. to support $ characters in the LDAP bindPW.
We're currently using a workaround there by defining an env variable ${DOLLAR} with value $.
#1051
#1382
Describe the solution you'd like to see
Add a toplevel config variable expandEnv which defaults to true (for compatibility with existing config files), but can be set to false by Dex admins who don't need variable expansion at all.
Describe alternatives you've considered
#1838
Additional context
I can make this change, but @sagikazarmark or @bonifaido can you tell me if such a PR would be accepted?
Current implementation:
These parts would be adapted in the PR.
func (s *Storage) UnmarshalJSON(b []byte) error {
// ...
if len(store.Config) != 0 {
data := []byte(os.ExpandEnv(string(store.Config)))
if err := json.Unmarshal(data, storageConfig); err != nil {
return fmt.Errorf("parse storage config: %v", err)
}
}
// ...
}
func (c *Connector) UnmarshalJSON(b []byte) error {
// ...
if len(conn.Config) != 0 {
data := []byte(os.ExpandEnv(string(conn.Config)))
if err := json.Unmarshal(data, connConfig); err != nil {
return fmt.Errorf("parse connector config: %v", err)
}
}
// ...
}
Is your feature request related to a problem? Please describe.
This is both a bug and a feature request.
The current way to expand env variables in the Dex config is error-prone, since it happens before the YAML parsing.
Therefore, weird hacks are needed e.g. to support
$characters in the LDAPbindPW.We're currently using a workaround there by defining an env variable
${DOLLAR}with value$.#1051
#1382
Describe the solution you'd like to see
Add a toplevel config variable
expandEnvwhich defaults totrue(for compatibility with existing config files), but can be set tofalseby Dex admins who don't need variable expansion at all.Describe alternatives you've considered
#1838
Additional context
I can make this change, but @sagikazarmark or @bonifaido can you tell me if such a PR would be accepted?
Current implementation:
These parts would be adapted in the PR.