Forum Discussion
Hi again,
nmrao wrote:Would you like to use randomNumber in test request such as SOAP or REST?
no - my goal for the plugin is even (much) more complex: I want to use a named ValueProvider but in addition, pass parameters to a concrete usage of this ValueProvider, such as
Value Provider Name ("valueName") == "vaultSecret"
and then use it like
${vaultSecret#some_path_within_a_Vault_instance_representing_a_secret_value}
Do you happen to know whether it's possible to pass such a property parameter value ("some_path_within_a_Vault_instance_representing_a_secret_value") into the ValueProvider class, i.e. can I access it using the PropertyExpansionContext that is passed to my
public String getValue(PropertyExpansionContext propertyExpansionContext) { (...) }
method?
Thanks a million one more time for your kind help! 👍
awl
Thank you for the details.
Somewhere it still not hit my brain, the final use case. But your use case seems to be interesting.
If I understand it better, probably can try something.
These are some other uses found for DataProviders found in the source, Not sure if that is of any help to you.
https://github.com/SmartBear/soapui/search?q=DynamicPropertyResolver
- awl3 years agoOccasional Contributor
Hi again, Rao,
nmrao wrote:Somewhere it still not hit my brain, the final use case. But your use case seems to be interesting.
If I understand it better, probably can try something.
These are some other uses found for DataProviders found in the source, Not sure if that is of any help to you.
https://github.com/SmartBear/soapui/search?q=DynamicPropertyResolver
and thanks for your continued help.
The use case is to read SoapUI property values dynamically (during the test run) from a secret external store (in our case, e.g. Vault, or the Pleasant Password Server, or even a Keepass file).
This will work fine if I can register a ValueProvider which does not provide a value for which no input parameters have been needed to calculate the result (like the random number, like the current test step or the project dir).
For my use case, it is crucial that the ValueProvider implementation, in the parameter that is passed to the getValue method, i.e. in the PropertyExpansionContext also gets this additional information from the property usage, i.e. instead of just
${vaultSecret}
I would configure
${vaultSecret#\\path\in\vault\to\database\password}
and then my custom ValueProvider code should be able to take "\\path\in\vault\to\database\password" from the PropertyExpansionContext and use it to "calculate", i.e.look this value up in Vault, and return it as the property's value.
Did I succeed in making myself clear enough now? 😉
I'll try to run SoapUI with the Java debugger attached, and then see what is available in the PropertyExpansionContext.
Thanks & best regards
awl
- nmrao3 years agoChampion Level 3Hoping that this is not directly related.
But a different approach to load the data into context with groovy script itself. It doe not require to Data provider. Using this approach, you should be able to achieve what you are looking for, I guess.
https://github.com/nmrao/sample-soapui-projects/tree/master/data-access
Here is another example where configuration is provided in external groovy and load that data from Project load script, again in context variable and retrieve where it is needed.
https://github.com/nmrao/sample-soapui-projects/tree/master/multipleEnvironmentsSingleConfig
Since these sample projects which are simple too to explore what they doing, you can try by grabbing them into the tool and see.- nmrao3 years agoChampion Level 3
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.
- nmrao3 years agoChampion Level 3Thanks for the details. I think getting more interesting use case.
I kind of searched for the same, found this
https://pleasantsolutions.com/info/pleasant-password-server/d-user-access-basics/setup-folder-permissions
So you want to extract password from database based on username (ranomNumber?) and the directory path as shown in the above path?
More over are you going to use jdbc step to query from database? If so, does it allow the path?
Related Content
- 20 days agoStoplight
- 5 years agoBostonKevin
- 4 years agohakonruud
Recent Discussions
- 14 days agosmilnik