Pass credentials to Jmeter command line - command-line

How can one pass credentials to the Jmeter command line to be used as username/password for HTTP Authorization Manager username/password? I'm using Jmeter 5.4.
I need to be able to programmatically pull credentials from a vault or Jenkins credentials and pass to Jmeter. Hard coding or writing to a file is not an option.

Normal way of parameterizing a JMeter test using external data is:
Use __P() function in the HTTP Authorization Manager like:
${__P(username,)}
it will return the username property value
Pass the username property to JMeter via -J command-line argument like:
jmeter -Jusername=johndoe -n -t test.jmx ....
Another option is reading the value from an environment variable using __groovy() function:
${__groovy(System.getenv('username'),)}
or if you have Custom JMeter Functions plugin installed you can do the same using __env() function
${__env(username,,)}

Related

use output of standalone java file as jmeter parameter

I have to create a load test for a post method and have to pass a token in the header manager. This token is generated by stand alone java file and is valid for 5 minutes only. For a manual run, I can generate the token separately and pass it on to jmeter, but want to configure the jmeter in jenkins.
I want to see if I can use that java file and jmeter together and pass that token as parameter. I need solutions for below:
How to implement java file and jmeter together?
As token is getting expired in 5 minutes so need a solution to check for token expiry and use new token.

How to inject username and password stored in vault to use in jenkinsfile (pipeline as a code)?

I have my username and password stored in Vault server. While using jenkins pipeline I want to use those credentials in my jenkinspipeline file to run adn ansible play that will use those credentials on the target machine to log in and perform tasks. How can i do that in jenkinsfile ?
Well I could figure out... the official documentation itself is wrong.
Correct usage is described here: https://issues.jenkins-ci.org/browse/JENKINS-45685

How to generate a swagger file for the header "Content-Type: application/x-www-form-urlencoded" in Informatica cloud?

I want to generate a swagger file for rest v2 connector in informatica cloud with these details.
POST CALL:
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Raw Body:
token=XXXXXXX&content=record&format=csv
But informatica cloud does not have an option of application/x-www-form-urlencoded.
I am able to do the same request in POSTMAN as POSTMAN has all the functionalities.
I even tried to put the Content-Type separately in the headers section while generating the swagger file in Informatica-cloud, but still didn't work.
Someone told me to use this website: http://specgen.apistudio.io for creating the swagger file, but the site does not seem secure and thus I cannot enter any sensitive data
Is there any way I could generate the file through a website or through informatica itself?
Swagger file cannot be generated for the header “Content-Type: application/x-www-form-urlencoded” in Informatica cloud.
What can be done instead is to use 'Curl' for the rest api call in the pre/post processing command in the Mapping Task/Data Synchronization Task. You can take a look at the curl commands in here:
https://www.baeldung.com/curl-rest
Other way if you want to avoid using Curl then, you can create a 'service connector' for the REST call in the application integration.
It is also possible to run data integration tasks from application integration if you want to run them after using the service connector.
The way it works is:
Create a service connector
Create the connection for the service connector
Create a process.
Inside the process, use various services. First service can run your API connection that you just made, then you can use other service to run a data integration task which is available inside 'System service: -> Run cloud task'.
This way you can make the work done without creating a swagger file as it does not accept “Content-Type: application/x-www-form-urlencoded”.

Bluemix binding WIoTP service using cf bind-service custom configuration

Cloud foundry provides facility to specify credentials as part of cf bind-service command. I am using this facility to specify custom credentials while binding WIoTP service to an app in Bluemix. As in below anonymized command
cf bind-service demo-app dev-iotf-service -c '{"apiKey":"a-dummyorg-dummy12345","apiToken":"dummyapikey","base_uri":"https://dummyorg.internetofthings.ibmcloud.com:443/api/v0001","http_host":"dummyorg.internetofthings.ibmcloud.com","iotCredentialsIdentifier":"dummyid","mqtt_host":"dummyorg.messaging.internetofthings.ibmcloud.com","mqtt_s_port":8883,"mqtt_u_port":1883,"org":"dummyorg"}'
I have generated service-key using cf create-service-key command.
Invalid configuration provided for -c flag. Please provide a valid
JSON object or path to a file containing a valid JSON object.
What am I doing wrong? Or is it that Bluemix,WIoTP currently doesn't support specifying custom credentials as part of cf bind-service command. I really don't want to go CUPs route as that would need change in quite a few apps which expect WIoTP credentials to be present in iotf-service object.
I can invoke the command exactly as you have specified (apart from substituting my app and service name) using bx client:
bx cf bind-service myapp my-iotf-service -c '{"apiKey":"a-dummyorg-dummy12345","apiToken":"dummyapikey","base_uri":"https://dummyorg.internetofthings.ibmcloud.com:443/api/v0001","http_host":"dummyorg.internetofthings.ibmcloud.com","iotCredentialsIdentifier":"dummyid","mqtt_host":"dummyorg.messaging.internetofthings.ibmcloud.com","mqtt_s_port":8883,"mqtt_u_port":1883,"org":"dummyorg"}'
and it works. Possibly you simply have an old cf client. You should use the bx client as available at https://console.bluemix.net/docs/cli/index.html#downloads
However, IoTP does not support this and so ignores anything sent via this means. The obvious case would be to either create a limited API key or use an API key you have already created as you are attempting. Unfortunately you would need to submit an idea at https://ibmcloud.ideas.aha.io/?category=6343565373323972470 to get it considered.

Pre-Authenticate Powershell WebClient requests to Team City 8.0 REST API

I'm trying to run Powershell scripts in my Team City build steps.
The scripts use WebClient to connect to Team City's REST API; currently, I have to login to Team City and hardcode a username and password as arguments in my Powershell build step.
I'm wondering if anyone knows a way to pass the credentials I am currently using to authenticate to Team City in my Powershell scripts without hardcoding any passwords
If you only need read access in the REST api (ie you don't want to do POST/PUT/DELETE, only GET) then use the teamcity generated user name and password.
This username/password pair is generated per each build and valid only during the build run. This is how you can access them in your powershell script:
read the $env:TEAMCITY_BUILD_PROPERTIES_FILE environment variable which holds the full path to the build properties file that are generated/valid for this build
this file is a simple key=value java prop file. You need to parse out the values for teamcity.auth.userId and teamcity.auth.password properties. Or better yet, parse all the props always in your script init phase and put them into a hash table in your powershell script.
If you need write access to the REST api, you can't use this uid/pwd pair. For this I am using a keychain on osx and a keepass db on windows. Keepass has a nice .net api that you can access from powershell. Create an new keepass db, make it unlockable with a key, not with a password, make sure your user running the build agent has access to this key and no one else, then use keepass api to unlock the db, read out your teamcity admin account and password who can do POST/PUT/DELETE in the rest api.
Thanks for the answer but we wound up providing the username and password as build parameters.
TeamCity's built in password protection helped us out here.
In this way, we're using one account to run our powershell scripts but we can still see who kicked off the build from the credentials they used to login to the web UI.
So we maintained traceable responsibility and stopped the constant entering of username and passwords.
More info: confluence.jetbrains.com/display/TCD7/Typed+Parameters