Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key validation #113

Open
dhardy opened this issue Oct 13, 2023 · 1 comment
Open

Key validation #113

dhardy opened this issue Oct 13, 2023 · 1 comment

Comments

@dhardy
Copy link

dhardy commented Oct 13, 2023

As noted here, it can be useful to validate that keys found in configuration files are known/accepted keys.

I haven't dived very far into how this crate works, but will try to lay out a strategy of how key validation could be supported:

  • Add a LayerSort descriptor for each layer: default value, read-only file, env, override, validator, etc.
  • In order to enable key validation, expect that default value layer(s) cover all supported keys
  • The validator, as a layer / plug-in / function-of-the-Config, will enumerate all keys and report an error for any key from a layer other than default values which does not override a key from a default-value layer.

Hopefully this is clear enough? My primary reason for creating this issue is actually to ask whether there is interest in supporting this — it requires a little more complexity from layers (adding LayerSort, ability to query values from each layer).

@matthiasbeyer
Copy link
Owner

Hm. So key validation as you mention it is really a concern, yes. Right now, the idea would be to rely on the deserialization method for key verification, which would be serde most of the time... serde already supports denying unknown fields - would this suffice?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants