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

2
votes

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

2
restauthenticationpowershellwebclientteamcity-8.0
If not hardcode them then when do you wish to supply Credentials to your powershell script? – Mitul
I'm trying to use the credentials I supplied to login to Team City, the only possible way any of these scripts can be run is through Team City web UI, after a username and password has been supplied to access the server – ShaneC

2 Answers

4
votes

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.

1
votes

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