ContributionsMost RecentMost LikesSolutionsRe: How are you securing secrets for storing your projects in github? Thanks both, gone with KarelHusa's solution, it allows me to get this into our companies GIT and get more hands on it. I'll have to explore if ADO is showing the credentials at a later date so may come back to your recommendation in the future nmrao How are you securing secrets for storing your projects in github? We're trying to migrate our ReadyAPI suites into github and I'm getting a little stuck with ReadyAPI's documentation on how to encrypt passwords we use to test our application, I'm hoping someone has a simple answer they can share. Our application passwords are stored in auth manager or request properties, when this project is converted to a composite project and pushed into github those values are visible so I have followed documentation to try and mask them without success. 1. Encrypt the project - this stops the project being a composite project so we're back to single use for upgrades and preventing people from making changes and keeping them in a branch. Doesn't seem like this fits. 2. Password protect the project - doesn't obsfucate the passwords anywhere. 3. Move the passwords to encrypted properties - Feels very hacky and clunky, makes the auth manager redundant and isn't very user friedly. I haven't been able to find any other in application solutions other than the above, I was looking at keystores/ truststores but neither seem to fit the requirement. This has left us with the only option we can see which is to write a groovyscript to pull the passwords out of an encrypted keepass kdbx file to use at runtime. This is not my preferred approach as I would rather use in built features with ReadyAPI support documentation... If anyone knows of other things to attempt or can share how they managed it in their project that would be appreciated. SolvedRe: Mask Password in settings.xml file for Composite Projects I support this, we are working around this with groovyscript and a kdbx file right now, I'd rather use in tool features. If ReadyAPI supports GIT it should make it very easy to encrypt any credentials used in the scripts imo. Re: After upgrade to ReadyAPI 3.4.6 all of my requests are failing as security header is no longer sent bobkaine thatsthat - I've just had and sorted the issue we were having, hopefully this helps you too. Before 3.4.0 the combination of request properties and environment managed the attributes to set the WS-Security attributes you needed. Since the upgrade you now need to set that in the WS-Security config. For our API it meant I needed to add a new entry in Outgoing WS-Security Configurations for every application credential for every environment and I added in just the Username attribute so it could take that username, password, nonce, password type and must understand which were the attributes our application wanted. This is the documentation from readyAPI on how to add the WS-Security attributes. Re: Getting InvalidSecurity error with Must Understand as None gpub Can you compare the raw request done on older readyAPI version vs the one on the newer one? For my companies API the new version of readyAPI wasn't sending in the mandatory values in the WS-Security header attributes. I have followed the documentation here to get them set up in their new structure and our requests are working again after the changes. For us we needed to have must understand: 1, nonce and a username and password so I just added the Username attrbute to the Outbound WS-Security config.