Can't pass password to the child build in Teamcity.
In the Teamcity project, there is a build that works fine. A password is requested and system login is used.
LOGIN %teamcity.build.triggeredBy.username%
PASSWORD %secure:teamcity.password.PASSWORD%
I create another build and I specify the first build as the child. Teamcity runs a child build with default parameters.
To send parameters to the child build, I create the following parameters in the parent:
reverse.dev.Buil_ID.PARAMETER
With all the usual parameters, this works fine, but the password is not transmitted. If the type of the password field is changed to Text - the password starts to be transmitted, but appears in the logs and parameters in the clear.
The variable PASSWORD as %secure:teamcity.password.PASSWORD% is moved to the project level. In the parent build, it is queried and works fine, the variable is not defined in the child build.
Define the password as %teamcity.auth.password% In this case, the hash password is passed. How to return it to its original form from hash?
Maybe there are other solutions to the problem?
It's security restrict of Teamcity.
There is two refers in the documentation about password type fields.
When using build parameters of type "Password", referencing them from a dependency such as %dep..password_parameter% will not retrieve the actual value. This is done for security reasons to prevent dependencies from accessing the value, thus restricting the possibility of unauthorized access to it.
Properties marked by the VCS support as secure (for example, passwords) are not available as reference properties.
Accordinly, reverse.dep. also won't work.
Related
To connect to DB I have to make an API call to generate a token. Lets say I store this in environment variable $TOKEN.
Now while setting up my data source in DataGrip, how can I tell DataGrip to read $TOKEN environment variable as its value will keep on changing? Because before opening DataGrip I will make the API call to generate the token and set in a environment variable via script.
Is it possible to read environment variable as a password in DataGrip?
There is no such feature out of the box.
You can create your custom plugin to provide this kind of authorisation. That is the matter of implementing of on class - com.intellij.database.dataSource.DatabaseAuthProvider
See this plugin as an example.
i have defined a dev.properties file for the mule flow.where i am passing the username and password required to run the flow.This password gets updated everymonth.So everymonth i have to deploy the code to the server after changing the password.Is there a way , where we can keep the properties file outside the code in mule server path.and change it when required in order to avoid redeployment.
One more idea is to completely discard any usage of a file to pickup the username and password.
Instead try using a credentials providing service, like a http requestor which is collecting the username and password from an independent API(child API/providing service).
Store it in a cache object-store of your parent API (the calling API). Keep using those values, unless the flow using them fails or if the client needs to expire them after a month. Later simply refresh them.
You can trigger your credentials providing service using a scheduler with a Cron expression having Monthly Triggers.
No, because even if the properties file is outside the application, properties are loaded on application deployment. So you would need to restart the application anyway to pick up the new values.
Instead you can create a custom module that read the properties from somewhere (a file, some service, etc), assign the value to a variable, and use the variable instead at execution time. Note that some configurations may only be set at deployment time, so variables will not be evaluated as such.
If the credentials are not exposing your application security or data, then you can move them to another config file(place it Outside mule app path). Generate a RAML file which will read & reload the credentials after application deploy/start-up, and store them in cache with timeToLive around 12 hours.
The next time when you have to change Username/Password, change in the file directly and cache will refresh it automatically after expiry time.
Actually not because all the properties secure properties needs to be there at runtime and is it is not there your application will get failed,
There is one way but it’s not best one, instead of editing code you can directly edit secure property I.e username and password in your case directly in cloudhub runtime manager properties tab.
After editing just apply changes then api will restart automatically and will deploy successfully
Currently deploying PostgREST in AWS. When I use Fargate and just hardcoded type in the environment variables for the connection string, the machine works like a charm.
However I recently replaced these values with secrets. In the secret I copy-pasted the entire string in the value and in the environment variable I set the source from "Value" to "ValueFrom".
So the value now is:
postgres://<myuser>:<mypass>#<amazon-rds-instance>:5432/<db>
When I use this connectionstring directly in the environment variable I can easily connect, so I know the information is correct.
The logs come back with the following error:
{"details":"missing \"=\" after \"{\"postgrest_db_connection\":\"postgres://myuser:mypass#amazon-rds-instance:5432/db\"}\" in connection info string\n","code":"","message":"Database connection error"}
I also checked I have no characters in the string that need to be escaped. What can I be missing here?
So I figured it out. Unfortunately this line was it:
It is only supported to inject the full contents of a secret as an environment variable. Specifying a specific JSON key or version is not supported at this time.
This means that whenever you use the secrets as ValueFrom setting in the environment variables (when working with Fargate), the entire secret's value gets copy-pasted.
I tested this using a secret for the PostgREST schema variable. I got back the value:
{'PGRST_SCHEMA_URL': 'public'}
Whilst I was expecting it to be just:
public
This is why the configuration went bad as well. Thanks everyone for searching.
I want to keep my Web Service username and password separately from SOAP UI Test XML file.
So, I save username and password as custom properties in external file called properties.xml.
But the problem is that after I manually import the property values (defined on the project level) and save the test, the values are added to the test XML file distinctly.
So, anybody who will open the test XML file after me, will be able to read the username and password in my property values. Which I do not want.
Inside the test XML file it looks like this:
<con:name>USERNAME</con:name><con:value>!MYUSERNAMEVALUE</con:value></con:property><con:property><con:name>PASSWORD</con:name><con:value>!MYPASSWORD</con:value>
Can I use reference to my username and password through the external file properties.xml, while automatically running the test, but not show values in test XML?
I thought this configuration would work:
<con:name>USERN</con:name><con:value>${projectDir\properties#USERNAME}</con:value></con:property><con:property><con:name>PASSWORD</con:name><con:value>${projectDir\properties#PASSWORD}</con:value>
or this one:
<con:name>USERN</con:name><con:value>${projectDir\properties.xml#USERNAME}</con:value></con:property><con:property><con:name>PASSWORD</con:name><con:value>${projectDir\properties.xml#PASSWORD}</con:value>
But they are not resolving the property values correctly.
I don't think you can use external files that way.
Either you add a groovy step that will extract the username and password from your file and then you make your webservice point to those recovered values,
Or, when using the testRunner (I guess you do so for automatically running the tests), you use the -P option that will set your values as Project custom properties. In that case, in your webService, you just have to point to those project properties.
example.
in your web service, set your username as ${#Project#username} and your password as ${#Project#password} and when you launch the testRunner you add the following options:
-Pusername=myUserName and -Ppassword=myPassword
refer to testRunner command-line arguments
I have authored an MSI that requires an account and password to be supplied to install and start a Windows Service, so I've added a couple of properties to my 'Product' element for that. I have a requirement that these properties should not need to be resupplied to perform an upgrade and since one of those properties is a password I don't want to persist it's value to the registry (or anywhere). I have achieved this with
<MajorUpgrade ... Schedule="afterInstallExecute" />
Now I'm authoring an exe bootstrapper to bundle this MSI with it's prerequisite, similarly the exe will need to receive values for the properties and pass them to the MSI, so I've added some 'Variable' elements to my bundle and passed them to my 'MsiPackage' element with child 'MsiProperty' elements. And this works great during first install when the values are supplied, but now when I want to upgrade the bundle without supplying values for the properties the bootstrapper passes empty values to the MSI. Something equivalent to...
msiexec /i MyMsi.msi ACCOUNT= PASSWORD=
Which breaks the upgrade. The new version of the Windows Service is attempting to start with an empty value for account and password.
Is there a way to conditionally pass variable values to MSI's as property values?
What happens when both the 'Variable' element attributes 'Hidden' and 'Persisted' are set? Will the password really be hidden?
Is there another pattern I don't know about / haven't thought of?
Something like this doesn't feel like it should require a custom action.
On upgrades you can disable the <InstallServices> standard action.
In one of the products I work with I have the following:
<!-- http://stackoverflow.com/questions/15965539/how-to-only-stop-and-not-uninstall-windows-services-when-major-upgrade-in-wix don't change service config on upgrade -->
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
<InstallServices>NOT WIX_UPGRADE_DETECTED OR V6INSTALLED</InstallServices>
Because I didn't want to reset the start types of the services is the user has decided to start them manually instead of automatically (it's an option in our product to set this).
By doing this, it should leave the service already installed as is when upgrading instead of trying to re-add it with empty parmeters for the login user/pass
An alternative is to make a salted hash of the password and store the user and salted&hashed password into the registry. On upgrades you can read these values decode the password and use those values.