AdditionalParameters is providing a CaseSensitive HashTable
Prerequisites
- [X] Write a descriptive title.
- [X] Make sure you are able to repro it on the latest released version
- [X] Search the existing issues.
Steps to reproduce
Register a new secret vault, vaultparameter for the database lowercase in one case, CamelCase the second time
Register-SecretVault -Name HashTableBugVault1 -ModuleName $modulePath -VaultParameters @{ database = "database" }
Register-SecretVault -Name HashTableBugVault2 -ModuleName $modulePath -VaultParameters @{ DataBase = "database" }
The vaultparameters are automatically provided to the extension via the [hashtable]$AdditionalParameters param.
Within the extension the provided hashtable uses case sensitive keys. E.g.
if (-not ($AdditionalParameters.database)) {
Write-Error "${VaultName}: `$AdditionalParameters.database not found"
return $false
}
fails for vault HashTableBugVault2.
A demo repository exists at https://github.com/Callidus2000/SecretManagement.HashTableBugs
Expected behavior
The database parameter should be available via `$AdditionalParameters.database` and `$AdditionalParameters.DataBase`.
Actual behavior
Test-SecretVault: HashTableBugVault2: $AdditionalParameters.database not found
Error details
No response
Environment data
Name Value
---- -----
PSVersion 7.3.1
PSEdition Core
GitCommitId 7.3.1
OS Microsoft Windows 10.0.19044
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Version
None
Visuals
No response
For other devs who want to create a new extension: I've included a workaround in my template module and in the corresponding ReadMe.
Returned secrets of type Hashtable also comeback as Case Sensitive, regardless of the vault implementation, I'm not sure if this is intended design or not now considering it's possible for a vault to be case sensitive.
If this is the case, I think it should be up to the Vault author to enforce the behavior.