Forum Discussion
Let us say, you have an object [name: 'user', path: 'root/client/client1']
If secret needed for each test differently, then use directly in the groovy script test step of the respective test case.
context.myVault = { [name: 'user', path:'/root/client/client1'] }
Let us assume, the annotation is @PluginValueProvider(valueName = "vaultSecret")
Now in the VaultSecretProvider class, you can access the 'myVault' inside of getValue() method by doing either of (not tested in java, but will work in groovy I believe)
propertyExpansionContext.getMyVault() or propertyExpansionContext.myVault
Similarly get the name and path as below inside getValue method
propertyExpansionContext.getMyVault().get('name') or propertyExpansionContext.myVault.name &
propertyExpansionContext.getMyVault().get('path') or propertyExpansionContext.myVault.path
In the same method, you can even execute query the database and retrieve value (which i guess is the secret) and return from getValue method.
To retrieve secret, try below.
context.vaultSecret
I wish I could try this one myself. This is all by imagination and little understand of what you have explained.
In case I were to do, I would choose groovy class for the Data provider instead of java. Of course, it is preference on individual.
If the valueSecret is fixed per execution of a project / fixed, then you can think of moving the above from groovy script to Project Load / Setup script so that it would do one time. And pass those details as project level parameters also while running.
EDIT:
Just rethinking if the above works or not.
If the data provider class is implemented in java, propertyExpansionContext.getMyVault() will fail the compilation as it does not know the run time added value. But if it is implemented in groovy, there are chances that it would pass the compilation.
All,
I just found out that most likely, in order to make the ValueProvider work with full property value expansion, I need to register a custom PropertyResolverFactory
https://www.soapui.org/developers-corner/custom-factories/
in order to allow to pass the additional path context parameter to the credential store (Vault, Pleasant, ...). The custom PropertyResolver needs to take this path into account in addition to what today's DynamicPropertyResolver does...
Many thanks Rao, for your help on the way to this finding - I think we can close this topic now.
Best regards,
awl
Related Content
- 2 months agoStoplight
- 5 years agoBostonKevin
- 4 years agohakonruud
Recent Discussions
- 6 days agoemoya