ReplaceTokens: Secret tokens with semicolon about cols-agent-tasks HOT 12 CLOSED

Hi @Shortcheese - which version of TFS/VSTS are you on? TFS 2015 update 3 and VSTS no longer require the "hack" for the Secrets, so you shouldn't be using the key/value pair string from the UI. Just add the secrets and leave the secrets value for the task blank.

If you're using an older version of TFS, then you will need the key-value pairs. The workaround I use is to use a tokenized string (instead of a token) for the connection string. In other words, use

Data Source=__dbServer__;Initial Catalog=__dbName__;User=__dbUser__;Password=__dbPassword__

for the value of the connection string and then create 4 variables instead of just 1.

from cols-agent-tasks.

I tried to use it without the hack running TFS2015 Update 3 and version 1.1.63 of the build & release tools . When I run it, I get a

"Token [WebconfigDatabaseCredentials] does not have an environment value"

warning in the log. And when I look at the converted web.config, I see no transformation:

"connectionstring="__WebconfigDatabaseCredentialsGuw__

I understand that I can use multiple tokens but when I have an application having multiple db connections, it would be nice when the hack is no longer necessary.

from cols-agent-tasks.

Hi @Shortcheese - two things:

1. Your connection string has a token for WebconfigDatabasecCredentialsGuw but the error message is reporting that WebconfigDatabaseCredentials does not exist. This is probably just the code you pasted for an example, but I thought I would confirm with you
2. Does your password have a $ character in it? I've seen sometimes that the $ char (which is a special char in PowerShell) does weird things. You can double any $ in your password (so if your password is $mil3y you can make it $$mil3y).

If neither of these applies, then can you share the log (set System.debug to true) - you can redact if necessary.

from cols-agent-tasks.

Hi @colindembovsky:

1. Yes, you are right. I cut the name, but forgot to cut in the second part. In the attached log I don't cut anything. Only redact things back to **.

2. No, neither one of the variables has a $. I tried by just giving the variable the simple text Hello world. But still no success.

1_Release.log.txt

from cols-agent-tasks.

Hi @Shortcheese - I see that there are variables for WebconfigDatabaseCredentialsCebes, Porta and Thinsy but there isn't a variable for WebconfigDatabaseCredentialsGuw. Are you sure you've defined that variable on the release or in the environment?

from cols-agent-tasks.

Yes, I'm Sure. I defined it as the online secret enviroment variable to test if I can use it as a secret one. Our security officier doens't like it when our passwords are open and we surelly want to use release manager because of our deployment mayhem we have now.

What I could think of is:

• Because it was a test, I did not define all four ( we have four enviroments per application) of the same enviroment variable secret. Maybe it will define the variable wrong. I will retry.

• I will remove the variable in all four of the enviroment and reinsert it. And retry the release.

from cols-agent-tasks.

Hi @Shortcheese - yes, this should definitely be a secret! Just remember that you can define variables at the release level and at each environment level. Also, if you clone and environment (say you clone Dev to Staging) then the secrets are actually cleared, even though the UI shows ***. You have to go and retype the values for all the secrets in the newly cloned environment.

Point is that from the log it seems that there isn't a variable called WebconfigDatabaseCredentialsGuw or it has no value (perhaps from cloning)?

from cols-agent-tasks.

I created a new release for testing purpose. This release has one environment with one variable. When I fill the variable The replace tokens replace it correctly. When I change the variable to secret it won't take it to replacement.
2016-12-23T10:05:30.4042932Z ##[debug]WebconfigDatabaseCredentialsGuw=undefined 2016-12-23T10:05:30.4042932Z ##[warning]Token [WebconfigDatabaseCredentialsGuw] does not have an environment value

When I use the secret tokens key:value it wil replace it correctly:
2016-12-23T10:09:48.6543778Z Replaced token [WebconfigDatabaseCredentialsGuw] with a secret value

But then a semicolon can not be used in a variable.

from cols-agent-tasks.

Can you give me an update

from cols-agent-tasks.

Hi @Shortcheese - when I look at the log of the WebconfigDatabaseCredentialsGuw I can see values for other vars but not that one:

2016-12-21T08:12:11.0261548Z 				[WEBCONFIGDATABASECREDENTIALSCEBES] --> [**]
2016-12-21T08:12:11.0261548Z 				[WEBCONFIGDATABASECREDENTIALSPORTA] --> [**]
2016-12-21T08:12:11.0261548Z 				[WEBCONFIGDATABASECREDENTIALSTHINSY] --> [**]

Can you try making the secret value "xyz" or something without special chars? I remember an issue where a password contained a $ and we had to make it $$ or it didn't work (it's a PowerShell string issue). Perhaps your issue is related?

from cols-agent-tasks.

I tried and tried..
What I found out is that parameters that are to long showing up in the initialize like
[WEBCONFIGDATABASECREDENTIALSPORTA] --> []
When I changed it to DatabasePortaPassword it doesn't show up in the initialize just like for example the parameter storing the deploymentmachine password.
But still even when I use XYZ as input it says

46 2017-03-08T11:59:57.4342298Z ##[debug]DatabasePortaPassword =undefined
47 2017-03-08T11:59:57.4342298Z ##[warning]Token [DatabasePortaPassword] does not have an environment value

even when I use the parameter where the machine password was stored (to connect to the iis machine where the application has to be installed) the log contains

##[debug]MachineUserPassword=undefined
##[warning]Token [MachineUserPassword] does not have an environment value

So it act a little bit weird.

from cols-agent-tasks.

I am experiencing the same issue. My secret connectionstring is replaced but excludes everything after semi-colon.

We are currently running a V1 version of the VSTS agent, maybe this has something to do with it?
I tried to leave secrets input field blank, but that does not work. So will go with the workaround mentioned by @colindembovsky in second post.

from cols-agent-tasks.